Changing compilation flags

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Changing compilation flags

arch general mailing list-2
>On 2016-10-24 05:56, Allan McRae wrote:
>*> 1) building gcc to enable PIE by default
*>
>I am in the middle of rebuilding gcc with --enable-default-pie. When it
>finishes, I will start a todo for rebuilding packages with static libraries.
>
>I also enabled --enable-default-ssp, which means that
>-fstack-protector-strong will be dropped from our CFLAGS (as it will be
>enforced by gcc) on the next opportunity.
>
>Bartłomiej

Does the -enable-default-ssp enforce also -fstack-check=specific to protect
from stack clash [1], gentoo do it (except on vlc and tcl which not build
but those are upstream bugs) [2]

[1] https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
[2] https://wiki.gentoo.org/wiki/Hardened/Gentoo_Hardened_and_Stack_Clash

*Pablo Lezaeta*
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing compilation flags

Alexander Harrigan
On On Sat, Jul 1, 2017 at 09:54 AM, arch-general <arch-
[hidden email]> wrote:

> >On 2016-10-24 05:56, Allan McRae wrote:

> >*> 1) building gcc to enable PIE by default

> *>

> >I am in the middle of rebuilding gcc with --enable-default-pie. When
it

> >finishes, I will start a todo for rebuilding packages with static
libraries.

> >

> >I also enabled --enable-default-ssp, which means that

> >-fstack-protector-strong will be dropped from our CFLAGS (as it will
be

> >enforced by gcc) on the next opportunity.

> >

> >Bartłomiej

>

> Does the -enable-default-ssp enforce also -fstack-check=specific to
protect

> from stack clash [1], gentoo do it (except on vlc and tcl which not build

> but those are upstream bugs) [2]

>

> [1] https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash

> [2] https://wiki.gentoo.org/wiki/Hardened/Gentoo_Hardened_and_Stack_Clash

>

> *Pablo Lezaeta*

>

No it doesn't but original plan [1] was to enable -fstack-check, -fno-plt and
-z,now to default flags in makepkg.conf. I hope Pacman maintainer will add
those before mass rebuild started so everythig will be done at once.

[1] https://lists.archlinux.org/pipermail/arch-dev-
public/2016-October/028405.html

\-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication
For everyone. https://www.msgsafe.io


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing compilation flags

arch general mailing list-2
On 07/01/2017 06:49 AM, Alexander Harrigan wrote:

> On On Sat, Jul 1, 2017 at 09:54 AM, arch-general <arch-
> [hidden email]> wrote:
>
> > >On 2016-10-24 05:56, Allan McRae wrote:
>
> > >*> 1) building gcc to enable PIE by default
>
> > *>
>
> > >I am in the middle of rebuilding gcc with --enable-default-pie. When
> it
>
> > >finishes, I will start a todo for rebuilding packages with static
> libraries.
>
> > >
>
> > >I also enabled --enable-default-ssp, which means that
>
> > >-fstack-protector-strong will be dropped from our CFLAGS (as it will
> be
>
> > >enforced by gcc) on the next opportunity.
>
> > >
>
> > >Bartłomiej
>
> >
>
> > Does the -enable-default-ssp enforce also -fstack-check=specific to
> protect
>
> > from stack clash [1], gentoo do it (except on vlc and tcl which not build
>
> > but those are upstream bugs) [2]
>
> >
>
> > [1] https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
>
> > [2] https://wiki.gentoo.org/wiki/Hardened/Gentoo_Hardened_and_Stack_Clash
>
> >
>
> > *Pablo Lezaeta*
>
> >
>
> No it doesn't but original plan [1] was to enable -fstack-check, -fno-plt and
> -z,now to default flags in makepkg.conf. I hope Pacman maintainer will add
> those before mass rebuild started so everythig will be done at once.
>
> [1] https://lists.archlinux.org/pipermail/arch-dev-
> public/2016-October/028405.html
>
> \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication
> For everyone. https://www.msgsafe.io
It is extremely hard to keep track of what you wrote here, and what you
are quoting from elsewhere (and who and where those quotes come from).
Can you please use an email client that actually works?

Thanks.

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing compilation flags

arch general mailing list-2
In reply to this post by arch general mailing list-2
I just looked into it and created simple patch. Anyone could test it and/or submit upstream?

Index: include/clang/Driver/Options.td
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -2497,6 +2497,7 @@
defm non_call_exceptions : BooleanFFlag<"non-call-exceptions">, Group<clang_ignored_f_Group>;
defm peel_loops : BooleanFFlag<"peel-loops">, Group<clang_ignored_gcc_optimization_f_Group>;
defm permissive : BooleanFFlag<"permissive">, Group<clang_ignored_f_Group>;
+defm plt : BooleanFFlag<"plt">, Group<clang_ignored_f_Group>;
defm prefetch_loop_arrays : BooleanFFlag<"prefetch-loop-arrays">, Group<clang_ignored_gcc_optimization_f_Group>;
defm printf : BooleanFFlag<"printf">, Group<clang_ignored_f_Group>;
defm profile : BooleanFFlag<"profile">, Group<clang_ignored_f_Group>;

Index: test/Driver/clang_f_opts.c
--- test/Driver/clang_f_opts.c
+++ test/Driver/clang_f_opts.c
@@ -275,12 +275,14 @@
// RUN: -fno-fat-lto-objects -ffat-lto-objects \
// RUN: -fno-merge-constants -fmerge-constants \
// RUN: -fno-caller-saves -fcaller-saves \
+// RUN: -fno-plt \
// RUN: -fno-reorder-blocks -freorder-blocks \
// RUN: -fno-schedule-insns2 -fschedule-insns2 \
// RUN: -fno-stack-check \
// RUN: -fno-check-new -fcheck-new \
// RUN: -ffriend-injection \
// RUN: -fno-implement-inlines -fimplement-inlines \
+// RUN: -fplt \
// RUN: -fstack-check \
// RUN: -fforce-addr \
// RUN: -malign-functions=100 \

> -------- Original Message --------
> Subject: Re: [arch-dev-public] Changing compilation flags
> From: [hidden email]
> To: Evangelos Foutras <[hidden email]>
> Daniel Micay <[hidden email]>, Public mailing list for Arch Linux development <[hidden email]>
>> So I think it would be a good idea to flip the default to -z,now in
>> the
>> linker if we"re going to use -fno-plt. I think they"d take a patch for
>> that upstream. Clang issue could be avoided with a 1 line patch adding
>> another no-op flag and they"d take that upstream. It"s harmless to use
>> the slower lazy linking calling convention when -fno-plt is passed.
> This is literally just +1 LOC for Clang b/c it has a system for adding
> no-op flags already, which is mostly used for GCC compatibility.
> It even uses it in cases that are quite dubious like making -fstack-
> check into a no-op, despite it not just being an optional optimization /
> code generation change like -fno-plt.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing compilation flags

arch general mailing list-2
In reply to this post by arch general mailing list-2
I see [1] -fstack-check is dropped and -fstack-protector-strong kept while being redundant. Anyone know what happened?
[1] https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pacman&id=0cd22d4454e0e1b3ae589b95274f808001465c15

On 2017-06-30 23:44, Allan McRae wrote:
>

On 30/06/17 19:07, Bartłomiej Piotrowski wrote:

>>

On 2016-10-24 05:56, Allan McRae wrote:

>>>

1) building gcc to enable PIE by default

>>

>>

I am in the middle of rebuilding gcc with --enable-default-pie. When it

>>

finishes, I will start a todo for rebuilding packages with static libraries.

>>

>>

I also enabled --enable-default-ssp, which means that

>>

-fstack-protector-strong will be dropped from our CFLAGS (as it will be

>>

enforced by gcc) on the next opportunity.

>>

>

>

Are you adding full RELRO + no-plt at the same time?

>

>

A

>

Yes, and -fstack-check=specific too, although I might drop no-plt if it
will cause too many builders.

Bartłomiej
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing compilation flags

arch general mailing list-2
In reply to this post by arch general mailing list-2
I testes some rebuilded binaries and BINDNOW isn't always enabled:
checksec -f /usr/bin/unrar
RELRO
Partial RELRO
checksec -f /usr/bin/qml (qt5-declarative)
RELRO
Partial RELRO
I don't know if -fno-plt was correctly passed but it's possible that build process doesn't work as intended. Maybe we need to patch binutils to enable z,now by default as Daniel advised?
On Wed Jul 5 16:51:55 UTC 2017, Daniel Micay wrote:
>There"s no loss of compatibility from only some code using it. The only
>issue with it is that immediate binding *must* be used to support it, so
>if CFLAGS is respected then LDFLAGS *must* be respected, or immediate
>binding needs to be set as the default in the linker(s).
On Wed Jul 5 19:04:51 UTC 2017 , Daniel Micay wrote:
>So I think it would be a good idea to flip the default to -z,now in the linker
>if we're going to use -fno-plt. I think they'd take a patch for that upstream.
>Clang issue could be avoided with a 1 line patch adding another no-op flag
>and they'd take that upstream. It's harmless to use the slower lazy linking
>calling convention when -fno-plt is passed. -fno-plt code is fully compatible
>with non -fno-plt code, the only requirement is that -fno-plt code is linked
>with -Wl,-z,now which works fine for non -fno-plt code too and is desirable
>for security either way.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing compilation flags

Bartłomiej Piotrowski-3
On 2017-07-12 18:25, Jordan Glover via arch-general wrote:

> I testes some rebuilded binaries and BINDNOW isn't always enabled:
> checksec -f /usr/bin/unrar
> RELRO
> Partial RELRO
> checksec -f /usr/bin/qml (qt5-declarative)
> RELRO
> Partial RELRO
> I don't know if -fno-plt was correctly passed but it's possible that build process doesn't work as intended. Maybe we need to patch binutils to enable z,now by default as Daniel advised?
> On Wed Jul 5 16:51:55 UTC 2017, Daniel Micay wrote:
>> There"s no loss of compatibility from only some code using it. The only
>> issue with it is that immediate binding *must* be used to support it, so
>> if CFLAGS is respected then LDFLAGS *must* be respected, or immediate
>> binding needs to be set as the default in the linker(s).
> On Wed Jul 5 19:04:51 UTC 2017 , Daniel Micay wrote:
>> So I think it would be a good idea to flip the default to -z,now in the linker
>> if we're going to use -fno-plt. I think they'd take a patch for that upstream.
>> Clang issue could be avoided with a 1 line patch adding another no-op flag
>> and they'd take that upstream. It's harmless to use the slower lazy linking
>> calling convention when -fno-plt is passed. -fno-plt code is fully compatible
>> with non -fno-plt code, the only requirement is that -fno-plt code is linked
>> with -Wl,-z,now which works fine for non -fno-plt code too and is desirable
>> for security either way.

The ongoing rebuild isn't about getting full RELRO, but recompiling
static libraries with PIE enabled. Another one that aims at removing
hardening-wrapper from repositories requires more attention to upstream
projects ignoring our compilation flags.

The plan is to modify binutils to enable BIND_NOW (for which Daniel
already provided me a patch), but it also requires some changes to make
test suite happy, so most likely I will work on it next Friday.

> I see [1]  -fstack-check is dropped and -fstack-protector-strong kept while being redundant. Anyone know what happened?
Current -fstack-check implementation is flawed[1] and after discussion
with Allan and Daniel, we have decided not to include it now. As even
now it would require entire repository to be rebuild, I don't see a
reason to do it now. I will get back to it when it's fixed.

[1] http://www.openwall.com/lists/oss-security/2017/06/19/9
Loading...