package/Makefile.in: Do not use CPPFLAGS for hardening options

The options for a full RELRO build should also be added to LDFLAGS.

Signed-off-by Stefan S?rensen <[email protected]>

The RELRO related flags are for the linker, not the compiler, so they belong in LDFLAGS.

Signed-off-by Stefan S?rensen <[email protected]>

---
 package/Makefile.in | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

package/Makefile.in +0 -0

index 1cbf34e0df..4525b8e79f 100644

Stefan,

Quoted 16 lines · Stefan S?rensen

The RELRO related flags are for the linker, not the compiler, so they belong in LDFLAGS.

Signed-off-by Stefan S?rensen <[email protected]>

---
 package/Makefile.in | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

package/Makefile.in +0 -0

index 1cbf34e0df..4525b8e79f 100644
@@ -141,9 +141,6 @@ ifeq ($(BR2_DEBUG_3),y)
 TARGET_DEBUGGING = -g3
 endif
 

package/Makefile.in ifeq ($(BR2_DEBUG_3),y) · line 146

Quoted 3 lines

package/Makefile.in +0 -3

-TARGET_CFLAGS_RELRO = -Wl,-z,relro
-TARGET_CFLAGS_RELRO_FULL = -Wl,-z,now $(TARGET_CFLAGS_RELRO)
-

If you remove these flags from CFLAGS then packages that link with gcc vs explicitly ld won't get the flag.

Stefan,

Quoted 16 lines · Stefan S?rensen

The RELRO related flags are for the linker, not the compiler, so they belong in LDFLAGS.

Signed-off-by Stefan S?rensen <[email protected]>

---
 package/Makefile.in | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

package/Makefile.in +0 -0

index 1cbf34e0df..4525b8e79f 100644
@@ -141,9 +141,6 @@ ifeq ($(BR2_DEBUG_3),y)
 TARGET_DEBUGGING = -g3
 endif
 

package/Makefile.in ifeq ($(BR2_DEBUG_3),y) · line 146

Quoted 3 lines

package/Makefile.in +0 -3

-TARGET_CFLAGS_RELRO = -Wl,-z,relro
-TARGET_CFLAGS_RELRO_FULL = -Wl,-z,now $(TARGET_CFLAGS_RELRO)
-

If you remove these flags from CFLAGS then packages that link with gcc vs explicitly ld won't get the flag.

Quoted 20 lines · Matthew Weber

Stefan,

Quoted 16 lines · Stefan S?rensen

The RELRO related flags are for the linker, not the compiler, so they belong in LDFLAGS.

Signed-off-by Stefan S?rensen <[email protected]>

---
 package/Makefile.in | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

package/Makefile.in +0 -0

index 1cbf34e0df..4525b8e79f 100644
@@ -141,9 +141,6 @@ ifeq ($(BR2_DEBUG_3),y)
 TARGET_DEBUGGING = -g3
 endif
 

Quoted 6 lines

package/Makefile.in ifeq ($(BR2_DEBUG_3),y) · line 146

Quoted 3 lines

package/Makefile.in +0 -3

-TARGET_CFLAGS_RELRO = -Wl,-z,relro
-TARGET_CFLAGS_RELRO_FULL = -Wl,-z,now $(TARGET_CFLAGS_RELRO)
-

If you remove these flags from CFLAGS then packages that link with gcc vs explicitly ld won't get the flag.

The intention is that LDFLAGS is used when linking with $CC/$CXX. Linking with
ld should ideally never be done, except for some special snowflakes like the kernel.

The intention is that TARGET_LDFLAGS is used in all linking invocation.
However, we're pretty sure that for a large number of packages, this isn't really the case. That's why we want to move more things into the wrapper.

The PIE build flags are only intended for building executables and can not be used in relocateable links (-r), static builds and shared library build - including the flags here causes build errors.

So instead of parsing the PIE flags directly on the command line to gcc, include them in a gcc spec file where it is possible to only apply the flags when other incompatible flags are not set.

This method and the spec files are from the Fedora build system.

Signed-off-by Stefan S?rensen <[email protected]>

Stefan,

Quoted 10 lines · Stefan S?rensen

The PIE build flags are only intended for building executables and can not be used in relocateable links (-r), static builds and shared library build - including the flags here causes build errors.

So instead of parsing the PIE flags directly on the command line to gcc, include them in a gcc spec file where it is possible to only apply the flags when other incompatible flags are not set.

This method and the spec files are from the Fedora build system.

Quoted 1 line

Signed-off-by Stefan S?rensen <[email protected]>

Thank you for this approach, I had a patchset reworking packages to deal with cases of "-r", static and shared. This eliminates that and makes a wrapper approach much easier as the next step.

Tested-by Matt Weber <[email protected]>

The PIE build flags are only intended for building executables and can not be used in relocateable links (-r), static builds and shared library build - including the flags here causes build errors.

So instead of parsing the PIE flags directly on the command line to gcc, include them in a gcc spec file where it is possible to only apply the flags when other incompatible flags are not set.

This method and the spec files are from the Fedora build system.

Signed-off-by Stefan S?rensen <[email protected]>

---
 package/Makefile.in         | 4 ++--
 toolchain/gcc-specs-pie-cc1 | 2 ++
 toolchain/gcc-specs-pie-ld  | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)
 create mode 100644 toolchain/gcc-specs-pie-cc1
 create mode 100644 toolchain/gcc-specs-pie-ld

package/Makefile.in +0 -0

index 4525b8e79f..141eb83946 100644

package/Makefile.in +0 -0

 endif
 
 ifeq ($(BR2_FORTIFY_SOURCE_1),y)

toolchain/gcc-specs-pie-cc1 new file +2 -0

new file mode 100644
index 0000000000..fc54bcb510
@@ -0,0 +1,2 @@
+*cc1_options:
++ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}

toolchain/gcc-specs-pie-ld new file +0 -0

new file mode 100644
index 0000000000..bd6b9071ff

toolchain/gcc-specs-pie-ld new file +1 -0

++ %{!static:%{!shared:%{!r:-pie}}}

The hardening options are compiler flags, not pure pre-processor flags, so put them in CFLAGS, not CPPFLAGS.

This fixes build errors where -D_FORTIFY_SOURCE=2 whas put in CPPFLAGS and then applied to configure tests which could fail since the required -O2 is only in CFLAGS.

Thanks for sending this series. When we added the initial support we debated on doing a few things differently at some point with how this is implemented. First, Buildroot uses a toolchain wrapper where it could inject these flags vs appending like the current design does.

Lastly there was discussion at the late developer days on integrating the checksec scripting so there was a way to do some validation of settings taking affect as part of new Buildroot test cases.

Quoted 4 lines · Matthew Weber

Thanks for sending this series. When we added the initial support we debated on doing a few things differently at some point with how this is implemented. First, Buildroot uses a toolchain wrapper where it could inject these flags vs appending like the current design does.

Personally I prefer that flags are appended - when injecting them through the wrapper, they are invisible in the build logs.

Quoted 3 lines

Lastly there was discussion at the late developer days on integrating the checksec scripting so there was a way to do some validation of settings taking affect as part of new Buildroot test cases.

I am working on integrating support for the annobin gcc plugin and adding a check step for hardening. I hope to have a RFC patch ready next week.

I'm not familiar with that plugin, I'd be curious if you're approach would allow us to define a few test scenarios to add to the Buildroot test suite.

Would the plugin require a internal toolchain build or just specific external prebuilt requirements?

Quoted 4 lines · Matthew Weber

Thanks for sending this series. When we added the initial support we debated on doing a few things differently at some point with how this is implemented. First, Buildroot uses a toolchain wrapper where it could inject these flags vs appending like the current design does.

Personally I prefer that flags are appended - when injecting them through the wrapper, they are invisible in the build logs.

Thanks for sending this series. When we added the initial support we debated on doing a few things differently at some point with how this is implemented. First, Buildroot uses a toolchain wrapper where it could inject these flags vs appending like the current design does. This would allow all the packages with flag ordering issues and no formal releases, to not carry a patch in buildroot for the long term.

The hardening options are compiler flags, not pure pre-processor flags, so put them in CFLAGS, not CPPFLAGS.

This fixes build errors where -D_FORTIFY_SOURCE=2 whas put in CPPFLAGS and then applied to configure tests which could fail since the required -O2 is only in CFLAGS.