Evaluate --enable-default-pie and --enable-default-ssp for GCC

[pierre]

Those two options are used by major distros and bring in some security. On the other hand, at least pie induces some performance penalty.

This ticket is for evaluating builds with those two switches, and reporting issues (in both LFS and BLFS) and progresses.

[pierre]

It looks like when building binutils with a toolchain built with default PIE, the SBU time increases by a few percents (Reports from Xi Ruoyao). default SSP seem to have no impact on SBU time.

[pierre]

Some GCC and binutils tests don't expect PIE to be used, and fail. There are two ongoing bug reports for GCC: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150 for default-pie and ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70230 for default-ssp. The gold test errors are in ​this bug report. None of those bugs are closed...

[pierre]

To get default pie for llvm, the following has to be passed to cmake: -DCLANG_DEFAULT_PIE_ON_LINUX=ON and archlinux has a patch for default stack-protector-strong: ​https://github.com/archlinux/svntogit-packages/blob/packages/clang/trunk/enable-fstack-protector-strong-by-default.patch

[pierre]

It seems distros disable libssp when building gcc. It's said that libssp might not be the best library for handling stack smashing (​https://wiki.osdev.org/Stack_Smashing_Protector). But I am not sure there is a replacement somewhere...

[pierre]

Looks like there is an implementation in glibc. So we should definitely disable libssp.

[Xi Ruoyao]

Replying to pierre:

Looks like there is an implementation in glibc. So we should definitely disable libssp.

We don't need to disable it. libssp is not used by default, and if the user wants to use it explicitly it's "his distro his rule". Just update the description for libssp to say "it's not used by default and the SSP helper functions in Glibc is used instead" will be enough.

[pierre]

In LLVM tests, built with the above modifications on a system with default-pie and default-ssp enabled for gcc, there are 6 failures (out of 62300+ tests). Those are not documented in the book. Note that the book documents 2 test failures that I don't see, but not sure the book is up to date...

[pierre]

There are 5 failures in llvm tests on a non default-pie/non default-ssp build. Interestingly, only three are in common with the 6 failures above.

• on non-pie/ssp:

  Failed Tests (5):
    Builtins-x86_64-linux :: extendhfsf2_test.c
    Builtins-x86_64-linux :: truncdfhf2_test.c
    Builtins-x86_64-linux :: truncsfhf2_test.c
    LLVM :: Other/ChangePrinters/DotCfg/print-changed-dot-cfg.ll
    LLVM :: tools/llvm-libtool-darwin/L-and-l.test
  

• on pie/ssp:

  Failed Tests (6):
    Builtins-x86_64-linux :: extendhfsf2_test.c
    Builtins-x86_64-linux :: truncdfhf2_test.c
    Builtins-x86_64-linux :: truncsfhf2_test.c
    DataFlowSanitizer-x86_64 :: custom.cpp
    DataFlowSanitizer-x86_64 :: origin_unaligned_memtrans.c
    LLVM :: tools/llvm-rc/windres-prefix.test
  

Notwithstanding that the book should be updated for test results, this does not seem to alarming...

[pierre]

rustc tests have exactly the same failures on both systems...

[pierre]

Replying to pierre:

There are 5 failures in llvm tests on a non default-pie/non default-ssp build. Interestingly, only three are in common with the 6 failures above.

• on non-pie/ssp:

  Failed Tests (5):
    Builtins-x86_64-linux :: extendhfsf2_test.c
    Builtins-x86_64-linux :: truncdfhf2_test.c
    Builtins-x86_64-linux :: truncsfhf2_test.c
    LLVM :: Other/ChangePrinters/DotCfg/print-changed-dot-cfg.ll
    LLVM :: tools/llvm-libtool-darwin/L-and-l.test
  

• on pie/ssp:

  Failed Tests (6):
    Builtins-x86_64-linux :: extendhfsf2_test.c
    Builtins-x86_64-linux :: truncdfhf2_test.c
    Builtins-x86_64-linux :: truncsfhf2_test.c
    DataFlowSanitizer-x86_64 :: custom.cpp
    DataFlowSanitizer-x86_64 :: origin_unaligned_memtrans.c
    LLVM :: tools/llvm-rc/windres-prefix.test
  

Notwithstanding that the book should be updated for test results, this does not seem too alarming...

[pierre]

Built firefox and all its recommended dependencies on the default-pie/ssp VM: Tests results are globally good (a few errors out of several thousands tests for some pacakges, or no failure for pacakges with a small number of tests), although I need to compare with a non-pie/ssp system, because the book does not seem to be up to date concerning tests documentation... Firefox itself seems to run normally.

[pierre]

All the ELF files in /usr/bin, /usr/sbin, and /opt/*/bin are pie executables, except... the gcc compiler itself and its associated programs (gcc-ar, gcc-nm, ...)

[Xi Ruoyao]

​https://gcc.gnu.org/r12-3530 contains an explanation:

The executables for GCC's c-family compilers must be built with no-PIE because they use PCH and the current model for this requires that the exe is always lauched at the same address. Since the other language compilers share code with the c-family this constraint is also applied to them.

[pierre]

It's weird: clang can use PCH files too, and clang is pie on the system with default-pie. Potential bug?

[Xi Ruoyao]

Replying to pierre:

It's weird: clang can use PCH files too, and clang is pie on the system with default-pie. Potential bug?

The implementation is different. AFAIK GCC implementation is just mmap() the PCH file into a pre-determined virtual address. And Clang cannot use the PCH files created by GCC (at all, with or without PIE), neither vice versa.

[pierre]

Replying to Xi Ruoyao:

Replying to pierre:

It's weird: clang can use PCH files too, and clang is pie on the system with default-pie. Potential bug?

The implementation is different. AFAIK GCC implementation is just mmap() the PCH file into a pre-determined virtual address. And Clang cannot use the PCH files created by GCC (at all, with or without PIE), neither vice versa.

Thanks for the explanation, that makes sense...

[pierre]

Owing to the good results up to now, I think we can include --enable-default-pie/ssp in the development book, and the option/patch for llvm in the blfs book. I have not evaluated on i686, though, so please speak up if you think it should be done before moving to it. Note that we can still add a "case" instruction on the gcc pages to prevent i686 from getting the default flags...

[Douglas R. Reno]

I'd say go ahead and drop it in. I need to do a build on i686 anyway since that machine has my WWAN card and I need it for my Wireless Networking class. I'll make it a full build, and I'll start today

[pierre]

Just pushed a "raw" commit with only instructions. What is needed in addition is:

• update changelog
• update command explanations
• comment on failing tests in binutils and gcc

I'll do that but not today

[pierre]

The following commits are related to this bug:

• 84e1bb6b8 Update changelog for PIE/SSP in GCC
• 63c2e8bb6 Comment on binutils test failures with pie/ssp
• c10a32737 gcc: fix link to PIE & SSP note
• e5aa02fe1 kernel: enable ASLR and SSP
• e502de1ab gcc: some reword of PIE/SSP/ASLR note
• 8d3b2541d gcc-pass1: fix bold "and" in command explanation
• 1bade3f43 Document the --enable-default-pie/ssp options
• 0611f706d Use default-pie and default-ssp flags in gcc

BLFS book has been updated too:

• ​ffa786a97 Update changelog for PIE/SSP
• ​08c7ccd31 Fix alphabetical order in glossary
• ​b89180f55 Add --enable-default-pie/ssp to gcc
• ​b84c40123 Add ASLR, PIE, and SSP to the glossary
• ​0472eb0f0 Add instructions for pie and ssp in clang

[Xi Ruoyao]

Can we close this as done now?

[Xi Ruoyao]

Some additional changes:

• 0d487e0 gcc: update sanity check command and output for default PIE
• fb5ad92 gcc: document that libssp is normally unused

Mark it fixed (though we may want to test it on 32-bit i686 later).

[Xi Ruoyao]

Replying to pierre:

Replying to Xi Ruoyao:

Replying to pierre:

It's weird: clang can use PCH files too, and clang is pie on the system with default-pie. Potential bug?

The implementation is different. AFAIK GCC implementation is just mmap() the PCH file into a pre-determined virtual address. And Clang cannot use the PCH files created by GCC (at all, with or without PIE), neither vice versa.

Thanks for the explanation, that makes sense...

Some news here: with GCC 13 we can use --enable-host-pie to build GCC itself with -fPIE. Not sure how much SBU increase doing so will cause...

They reverted the change.