[opensuse-factory] Enabling PIE globally

Marcus Meissner

5 Jan 2015 5 Jan '15

09:10

Hi, short: Marcus wants to enable PIE support globally. long version: To make programs less affected by buffer overflows and similar exploits, one feature is "address space layout randomization" aka "ASLR". We randomize various parts of the address space already, stack, mmaps, libraries and the vdso. e.g. for /usr/bin/cat: cat /proc/self/maps 00400000-0040c000 r-xp 00000000 08:01 397387 /usr/bin/cat 0060b000-0060c000 r--p 0000b000 08:01 397387 /usr/bin/cat 0060c000-0060d000 rw-p 0000c000 08:01 397387 /usr/bin/cat binary not randomized. 007d5000-007f6000 rw-p 00000000 00:00 0 [heap] heap not randomized. 7f530a549000-7f530a6ee000 r-xp 00000000 08:01 220 /lib64/libc-2.18.so ... 7f530ab17000-7f530ab18000 rw-p 00020000 08:01 52 /lib64/ld-2.18.so 7f530ab18000-7f530ab19000 rw-p 00000000 00:00 0 7fff71086000-7fff710a7000 rw-p 00000000 00:00 0 [stack] 7fff711fa000-7fff711fc000 r-xp 00000000 00:00 0 [vdso] everything randomized ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] not randomized, but should be safe To randomize the binary and heap the binary needs to be packaged using the PIE options of the compiler. (PIE == Position Independend Executable) This needs to be done during compilation (-fPIE) and during linking (-pie), which makes it harder to implement. Advantages of PIE: - a bit more secure (e.g. the major "codename" issues from 2014 (Heartbleed, Shellshock, Poodle) would not have been avoided...) Disadvantages of PIE: - There had been performance concerns, but these are mostly relevant for i586 due to low number of processor registers (and there like 5-10%). On other platforms but i586 there should be no performance decrease. I adjusted some endangered packages manually, but it would be better to do this globally. Just changing %optflags / RPM_OPT_FLAGS is insufficient as the linker also needs to be called specifically and this cannot be passed in via the configuration. Methods I am currently thinking about: - Change the compiler directly to build PIE binaries by default (change in gcc) Binaries that do not want it, would need to use -no-pie / -fno-PIE Advantage: - only some changes in .spec file where it is not wanted - would work for more than just the spec files using %configure or %cmake macros - Change the %configure RPM macro to pass the PIE flags in by default (change in rpm) Advantage: - only some .spec files need to be changed where it is not wanted Disadvantage: - %configure would need an option to disable PIE for apps that break (- manually changing all RPMs: not feasible) Any comments? I would try to work the gcc approach when I am back to work as time permits :/ Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Tomáš Chvátal

5 Jan 5 Jan

09:27

Dne Po 5. ledna 2015 10:10:04, Marcus Meissner napsal(a): I ommited quoting to shorten my response :) Overall the idea of hardening is great. There really is no real impact on other than i586 platforms. I would actually be glad if we do more nifty stuff taking from gentoo hardening. http://wiki.gentoo.org/wiki/Hardened/Toolchain Overall the approach should be this all should be included directly in our compiler, with some opt out cflags/ldflags switch, but by default on, it is better than having to edit bazilion of spec files one by one. Cheers Tom

Marcus Meissner

9 Jan 9 Jan

16:24

On Mon, Jan 05, 2015 at 10:27:45AM +0100, Tomáš Chvátal wrote:

...

Dne Po 5. ledna 2015 10:10:04, Marcus Meissner napsal(a):

I ommited quoting to shorten my response :)

Overall the idea of hardening is great.

There really is no real impact on other than i586 platforms.

I would actually be glad if we do more nifty stuff taking from gentoo hardening.

http://wiki.gentoo.org/wiki/Hardened/Toolchain

of this we do this for a lot of years now: Default addition of the Stack Smashing Protector (SSP) -fstack-protector is in $RPM_OPT_FLAGS since SLES 10 and SUSE Linux 10.0 and -D_FORTIFY_SOURCE=2 is in $RPM_OPT_FLAGS since SLES 10 and SUSE Linux 10.0 Default to marking read-only, sections that can be so marked after the loader is finished (RELRO) Enabled in binutils directly since SUSE Linux 10.1 and SLES 10 Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides. See caveats in gentoo page too, it might have negative drawbacks. Automatic generation of Position Independent Executables (PIEs) This just started project.

...

Overall the approach should be this all should be included directly in our compiler, with some opt out cflags/ldflags switch, but by default on, it is better than having to edit bazilion of spec files one by one.

I am tracking this in bug https://bugzilla.suse.com/show_bug.cgi?id=912298 now. Richi found a Gentoo patch submitted for GCC 5.0 inclusion which enables PIE by default. He seems kind of reluctant to have a SUSE specific patch. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

16:28

On Friday 2015-01-09 17:24, Marcus Meissner wrote:

...

Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez

18:41

El 09/01/15 a las 13:28, Jan Engelhardt escribió:

...

On Friday 2015-01-09 17:24, Marcus Meissner wrote:

...
Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing?

A fix for this one --> http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html is missing for example. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

14 Jan 14 Jan

13:44

On Fri, Jan 09, 2015 at 05:28:03PM +0100, Jan Engelhardt wrote:

...

On Friday 2015-01-09 17:24, Marcus Meissner wrote:

...
Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing?

glibc --enable-bind-now only seems to affect glibc. This needs to be done per package (or globally in the linker). Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez

15:26

El 14/01/15 a las 10:44, Marcus Meissner escribió:

...

On Fri, Jan 09, 2015 at 05:28:03PM +0100, Jan Engelhardt wrote:

...
On Friday 2015-01-09 17:24, Marcus Meissner wrote:

...
Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing?

glibc --enable-bind-now only seems to affect glibc.

This needs to be done per package (or globally in the linker).

I think we should do that globally.. and fix the known packages that break (X most notably, passing -z lazy in the package LDFLAGS) ..ohh and see what performance hit we get from that.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

15:41

On Wednesday 2015-01-14 14:44, Marcus Meissner wrote:

...

...
...
Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing?

glibc --enable-bind-now only seems to affect glibc. This needs to be done per package (or globally in the linker).

With all the symbols that C++ libraries have, this would seem overly expensive. Has anyone measured this before global enablement? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

15:44

On Wed, Jan 14, 2015 at 04:41:17PM +0100, Jan Engelhardt wrote:

...

On Wednesday 2015-01-14 14:44, Marcus Meissner wrote:

...
...
...
Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing?

glibc --enable-bind-now only seems to affect glibc. This needs to be done per package (or globally in the linker).

With all the symbols that C++ libraries have, this would seem overly expensive. Has anyone measured this before global enablement?

I am not thinking we should enable bind-now globally as it might have weird effects. (I am only planning on PIE right now.) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Biener

15 Jan 15 Jan

08:25

On Wed, 14 Jan 2015, Marcus Meissner wrote:

...

On Wed, Jan 14, 2015 at 04:41:17PM +0100, Jan Engelhardt wrote:

...
On Wednesday 2015-01-14 14:44, Marcus Meissner wrote:

...
...
...
Missing: Default full binding at load-time (BIND_NOW) It was not fully understood how this operates with dlopen and also with LD_PRELOADed overrides.

See caveats in gentoo page too, it might have negative drawbacks.

glibc is configured with --enable-bind-now, so is it really missing?

glibc --enable-bind-now only seems to affect glibc. This needs to be done per package (or globally in the linker).

With all the symbols that C++ libraries have, this would seem overly expensive. Has anyone measured this before global enablement?

I am not thinking we should enable bind-now globally as it might have weird effects.

(I am only planning on PIE right now.)

Note that PIE by itself has quite a cost on startup time due to having way more relocations and thus touching more pages at startup time (apart from the increase in binary size, of course), also leading to less pages being shared across programs. Richard. -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dimstar / Dominique Leuenberger

5 Jan 5 Jan

09:39

On Mon, 2015-01-05 at 10:10 +0100, Marcus Meissner wrote:

...

Hi,

short: Marcus wants to enable PIE support globally.

long version: To make programs less affected by buffer overflows and similar exploits, one feature is "address space layout randomization" aka "ASLR".

Marcus, Thanks for taking this initiative! It's a great way to ensure we do the right things in the best possible approach.

...

Disadvantages of PIE: - There had been performance concerns, but these are mostly relevant for i586 due to low number of processor registers (and there like 5-10%). On other platforms but i586 there should be no performance decrease.

Do we want to address that performance issue on i586 (which openSUSE is still built for) by having the i586 not PIE enabled?

...

Methods I am currently thinking about: - Change the compiler directly to build PIE binaries by default (change in gcc) Binaries that do not want it, would need to use -no-pie / -fno-PIE

Advantage: - only some changes in .spec file where it is not wanted - would work for more than just the spec files using %configure or %cmake macros

That seems indeed like the one-fix-catch-it-all approach (almost, packages using gold might still need to be touched) Cheers and happy new year! Dominique -- Dimstar / Dominique Leuenberger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

9 Jan 9 Jan

16:24

On Mon, Jan 05, 2015 at 10:39:41AM +0100, Dimstar / Dominique Leuenberger wrote:

...

On Mon, 2015-01-05 at 10:10 +0100, Marcus Meissner wrote:

...
Hi,

short: Marcus wants to enable PIE support globally.

long version: To make programs less affected by buffer overflows and similar exploits, one feature is "address space layout randomization" aka "ASLR".

Marcus,

Thanks for taking this initiative! It's a great way to ensure we do the right things in the best possible approach.

...
Disadvantages of PIE: - There had been performance concerns, but these are mostly relevant for i586 due to low number of processor registers (and there like 5-10%). On other platforms but i586 there should be no performance decrease.

Do we want to address that performance issue on i586 (which openSUSE is still built for) by having the i586 not PIE enabled?

Once we have a method we can test it, and probably do an %ifarch if needed.

...

...
Methods I am currently thinking about: - Change the compiler directly to build PIE binaries by default (change in gcc) Binaries that do not want it, would need to use -no-pie / -fno-PIE

Advantage: - only some changes in .spec file where it is not wanted - would work for more than just the spec files using %configure or %cmake macros

That seems indeed like the one-fix-catch-it-all approach (almost, packages using gold might still need to be touched)

gcc seems the way to go. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

İsmail Dönmez

5 Jan 5 Jan

09:50

On 05 Jan 10:10, Marcus Meissner wrote:

...

Methods I am currently thinking about: - Change the compiler directly to build PIE binaries by default (change in gcc) Binaries that do not want it, would need to use -no-pie / -fno-PIE

I would say go for this method. Our toolchain should be as secure as it could be by default. Also PIE slowdown on x86 should be negligible with recent kernels. Regards, ismail

Jan Engelhardt

10:41

On Monday 2015-01-05 10:10, Marcus Meissner wrote:

...

This needs to be done during compilation (-fPIE) and during linking (-pie), which makes it harder to implement.

Just changing %optflags / RPM_OPT_FLAGS is insufficient as the linker also needs to be called specifically and this cannot be passed in via the configuration. Methods I am currently thinking about: - Change the compiler directly to build PIE binaries by default (change in gcc) Binaries that do not want it, would need to use -no-pie / -fno-PIE

Most software uses the frontend binary/binaries for both compilation and linking rather than the individual tools, so if the frontend were to see -pie/-PIE during -c, it should convert that to -fpie/-fPIE, and -pie/-pie when linking. With that, we could switch everything with %optflags/CFLAGS alone. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Linda Walsh

9 Jan 9 Jan

20:10

New subject: [opensuse-factory] Re: Enabling PIE globally

Marcus Meissner wrote:

...

Hi,

short: Marcus wants to enable PIE support globally.

How does PIE interact with -fpic or -fPIC? Are they orthogonal or exclusive options? How does randomizing code location affect code locality and cache usage (not just /core, but L2 caches shared between paired cores , and L3 cores shared between all cores on a socket? The first may be a matter of 6 vs. half-dozen, but the second...I am unsure of. Third issue -- right now code seems [most?] often generated for "generic" x86 and x586. How will you tell the compiler generating for 'generic', that it should NOT limit itself to the lowest common denominator w/regards to register usage (586)? "march=core2" or march=native? What does PIE give over 'pic'? ---- From this: -fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. When this flag is set, the macros "__pic__" and "__PIC__" are defined to 1. -fPIC If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. Position-independent code requires special support, and therefore works only on certain machines. When this flag is set, the macros "__pic__" and "__PIC__" are defined to 2. -fpie -fPIE These options are similar to -fpic and -fPIC, but generated position independent code can be only linked into executables. Usually these options are used when -pie GCC option is used during linking. -fpie and -fPIE both define the macros "__pie__" and "__PIE__". The macros have the value 1 for -fpie and 2 for -fPIE. -------------- From the above it looks like fpic is more flexible and provides similar features for relocating the final segments -- i.e. PIE code can't be used in libraries (it seems? -- "only linked into executables??) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt

21:12

New subject: [opensuse-factory] Re: Enabling PIE globally

On Friday 2015-01-09 21:10, Linda Walsh wrote:

...

Marcus Meissner wrote:

...
Hi,

short: Marcus wants to enable PIE support globally.

How does PIE interact with -fpic or -fPIC? Are they orthogonal or exclusive options? What does PIE give over 'pic'?

Exclusive. In decreasing order, there is PIC, PIE, and then no cake at all. The manpage claims PIE code can only end up in executables, but at least on x86_64, it is possible to use PIE objects for a shared library as well.

...

How does randomizing code location affect code locality and cache usage

It should just enable the randomization of the section start addresses; what follows is still linear and not fragmented.

...

Third issue -- right now code seems [most?] often generated for "generic" x86 and x586. How will you tell the compiler generating for 'generic', that it should NOT limit itself to the lowest common denominator w/regards to register usage (586)? "march=core2" or march=native?

For x86ish: -mfpmath=sse plus {one or more of -msse, -msse2, -mavx, whatyoulike}. For other targets, just using -maltivec/-mvis may be enough. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab

12 Jan 12 Jan

08:49

New subject: [opensuse-factory] Re: Enabling PIE globally

Marcus Meissner writes:

...

short: Marcus wants to enable PIE support globally.

And why didn't you bother to test it? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

11:03

New subject: [opensuse-factory] Re: Enabling PIE globally

On Mon, Jan 12, 2015 at 09:49:37AM +0100, Andreas Schwab wrote:

...

Marcus Meissner writes:

...
short: Marcus wants to enable PIE support globally.

And why didn't you bother to test it?

I did download the RPMs and verify "file binary" output. I might have forgotten it for "grep", which you seem to have fixed now. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Schwab

11:13

New subject: [opensuse-factory] Re: Enabling PIE globally

Marcus Meissner writes:

...

On Mon, Jan 12, 2015 at 09:49:37AM +0100, Andreas Schwab wrote:

...
Marcus Meissner writes:

...
short: Marcus wants to enable PIE support globally.

And why didn't you bother to test it?

I did download the RPMs and verify "file binary" output.

It's also important to look at the log file: [ 100s] I: File is compiled without RPM_OPT_FLAGS Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bernhard Voelker

20 Jan 20 Jan

22:25

On 01/05/2015 10:10 AM, Marcus Meissner wrote:

...

short: Marcus wants to enable PIE support globally.

FWIW Fedora guys are also discussing (how) to enable PIE: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/203065/ https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-ind... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bernhard Voelker

21 Jan 21 Jan

11:31

On 01/20/2015 11:25 PM, Bernhard Voelker wrote:

...

On 01/05/2015 10:10 AM, Marcus Meissner wrote:

...
short: Marcus wants to enable PIE support globally.

FWIW Fedora guys are also discussing (how) to enable PIE:

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/203065/ https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-ind...

Turning on PIE via CFLAGS/LDFLAGS is a problem for projects where the ELFs are built differently, e.g. in coreutils all normal executables can be built with PIE, but this breaks building the shared library libstdbuf.so. The advantage of the Fedora approach is that the additional specs file takes care of this. --- hardened-cc1 --- *cc1_options: + %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}} --- hardened-ld --- *self_spec: + %{!shared:-pie} *link: + -z now and then $ export CFLAGS='-specs=hardened-cc1' $ export LDFLAGS='-specs=hardened-ld' $ configure ... I hacked it into my copy of coreutils, and it seems to work - also the testsuite passes. ;-) https://build.opensuse.org/project/monitor/home:bernhard-voelker:pie TBH I'm not very familiar with such GCC specs files, so would someone with more foo tell if this is a good approach (done centrally, of course, with the possibility to turn off hardening similar to what Fedora proposes)? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

11:55

On Wed, Jan 21, 2015 at 12:31:11PM +0100, Bernhard Voelker wrote:

...

On 01/20/2015 11:25 PM, Bernhard Voelker wrote:

...
On 01/05/2015 10:10 AM, Marcus Meissner wrote:

...
short: Marcus wants to enable PIE support globally.

FWIW Fedora guys are also discussing (how) to enable PIE:

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/203065/ https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-ind...

Turning on PIE via CFLAGS/LDFLAGS is a problem for projects where the ELFs are built differently, e.g. in coreutils all normal executables can be built with PIE, but this breaks building the shared library libstdbuf.so.

The advantage of the Fedora approach is that the additional specs file takes care of this.

--- hardened-cc1 --- *cc1_options: + %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}

--- hardened-ld --- *self_spec: + %{!shared:-pie}

*link: + -z now

and then

$ export CFLAGS='-specs=hardened-cc1' $ export LDFLAGS='-specs=hardened-ld' $ configure ...

I hacked it into my copy of coreutils, and it seems to work - also the testsuite passes. ;-) https://build.opensuse.org/project/monitor/home:bernhard-voelker:pie

TBH I'm not very familiar with such GCC specs files, so would someone with more foo tell if this is a good approach (done centrally, of course, with the possibility to turn off hardening similar to what Fedora proposes)?

Our GCC developers can take care of it. H.J.Lu is working on a PIE default enablement branch, not sure if this branch will make gcc 5.0. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Biener

12:35

On Wed, 21 Jan 2015, Marcus Meissner wrote:

...

On Wed, Jan 21, 2015 at 12:31:11PM +0100, Bernhard Voelker wrote:

...
On 01/20/2015 11:25 PM, Bernhard Voelker wrote:

...
On 01/05/2015 10:10 AM, Marcus Meissner wrote:

...
short: Marcus wants to enable PIE support globally.

FWIW Fedora guys are also discussing (how) to enable PIE:

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/203065/ https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-ind...

Turning on PIE via CFLAGS/LDFLAGS is a problem for projects where the ELFs are built differently, e.g. in coreutils all normal executables can be built with PIE, but this breaks building the shared library libstdbuf.so.

The advantage of the Fedora approach is that the additional specs file takes care of this.

--- hardened-cc1 --- *cc1_options: + %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}

--- hardened-ld --- *self_spec: + %{!shared:-pie}

*link: + -z now

and then

$ export CFLAGS='-specs=hardened-cc1' $ export LDFLAGS='-specs=hardened-ld' $ configure ...

I hacked it into my copy of coreutils, and it seems to work - also the testsuite passes. ;-) https://build.opensuse.org/project/monitor/home:bernhard-voelker:pie

TBH I'm not very familiar with such GCC specs files, so would someone with more foo tell if this is a good approach (done centrally, of course, with the possibility to turn off hardening similar to what Fedora proposes)?

Our GCC developers can take care of it.

H.J.Lu is working on a PIE default enablement branch, not sure if this branch will make gcc 5.0.

We also still have a patch in GCC that allows you to place a defaults.spec file into /usr/lib*/gcc/*-suse-linux/*/ with the above contents. We used that to supply a gcc-z9 package that just does that. Thus you could add a gcc-PIE package that contains such a specs file and that would change default behavior of GCC. Thus then simply add BuildRequires: gcc-PIE Richard. -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Bernhard Voelker

1 Feb 1 Feb

22:05

On 01/05/2015 10:10 AM, Marcus Meissner wrote:

...

short: Marcus wants to enable PIE support globally.

What is the status on this? I saw several packages where the .spec file has been changed manually with a SR to enable PIE builds, but I also saw that some packages are built with "CFLAGS=-fpie" automatically (... yet without "LDFLAGS=-pie"). Thanks & have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner

5 Feb 5 Feb

14:57

On Sun, Feb 01, 2015 at 11:05:37PM +0100, Bernhard Voelker wrote:

...

On 01/05/2015 10:10 AM, Marcus Meissner wrote:

...
short: Marcus wants to enable PIE support globally.

What is the status on this? I saw several packages where the .spec file has been changed manually with a SR to enable PIE builds, but I also saw that some packages are built with "CFLAGS=-fpie" automatically (... yet without "LDFLAGS=-pie").

I stopped this edit every package. I worked with Richi and there will be a "gcc-PIE" package which enables PIE building when installed. We can add this package to "Support:" in the project config, so packages do not need to be touched. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

3369

Age (days ago)

3400

Last active (days ago)

List overview

Download

24 comments

10 participants

participants (10)

Andreas Schwab
Bernhard Voelker
Cristian Rodríguez
Dimstar / Dominique Leuenberger
İsmail Dönmez
Jan Engelhardt
Linda Walsh
Marcus Meissner
Richard Biener
Tomáš Chvátal

[opensuse-factory] Enabling PIE globally

tags

participants (10)