diff mbox series

[1/2] stack protector: moved option to security menu

Message ID 1508901900-11190-1-git-send-email-matthew.weber@rockwellcollins.com
State Changes Requested
Headers show
Series [1/2] stack protector: moved option to security menu | expand

Commit Message

Matt Weber Oct. 25, 2017, 3:24 a.m. UTC 
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
---
 Config.in | 114 ++++++++++++++++++++++++++++++++------------------------------
 1 file changed, 59 insertions(+), 55 deletions(-)

Comments

Arnout Vandecappelle Oct. 25, 2017, 7:53 a.m. UTC | #1 
On 25-10-17 05:24, Matt Weber wrote:
> +menu "Security Hardening Options"

 This is bikeshedding of course, but I don't like submenus too much. They make
it harder to find the options IMO. For the Advanced options it is good that it's
a bit hidden, but I think the security options should be pretty in-your-face.

 I do understand though that we want some subdivisions in the menu structure so
the options that belong together stand out more. Would it be possible to achieve
the same with comments?

 Regards,
 Arnout
Matt Weber Oct. 25, 2017, 12:51 p.m. UTC | #2 
Arnout,

On Wed, Oct 25, 2017 at 2:53 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
> On 25-10-17 05:24, Matt Weber wrote:
>> +menu "Security Hardening Options"
>
>  This is bikeshedding of course, but I don't like submenus too much. They make
> it harder to find the options IMO. For the Advanced options it is good that it's
> a bit hidden, but I think the security options should be pretty in-your-face.
>
>  I do understand though that we want some subdivisions in the menu structure so
> the options that belong together stand out more. Would it be possible to achieve
> the same with comments?
>

I think we could.  I misunderstood your feedback on this back in Aug
and thought pulling those options out of Advanced meant another menu.
I'll wait to see if there is other feedback today and propose a v2
with that update.

Matt
diff mbox series

Patch

diff --git a/Config.in b/Config.in
index 814dc02..f3c9dcd 100644
--- a/Config.in
+++ b/Config.in
@@ -566,61 +566,6 @@  config BR2_GOOGLE_BREAKPAD_INCLUDE_FILES
 endif
 
 choice
-	bool "build code with Stack Smashing Protection"
-	default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
-	depends on BR2_TOOLCHAIN_HAS_SSP
-	help
-	  Enable stack smashing protection support using GCC's
-	  -fstack-protector option family.
-
-	  See
-	  http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt
-	  for details.
-
-	  Note that this requires the toolchain to have SSP support.
-	  This is always the case for glibc and eglibc toolchain, but is
-	  optional in uClibc toolchains.
-
-config BR2_SSP_NONE
-	bool "None"
-	help
-	  Disable stack-smashing protection.
-
-config BR2_SSP_REGULAR
-	bool "-fstack-protector"
-	help
-	  Emit extra code to check for buffer overflows, such as stack
-	  smashing attacks. This is done by adding a guard variable to
-	  functions with vulnerable objects. This includes functions
-	  that call alloca, and functions with buffers larger than 8
-	  bytes. The guards are initialized when a function is entered
-	  and then checked when the function exits. If a guard check
-	  fails, an error message is printed and the program exits.
-
-config BR2_SSP_STRONG
-	bool "-fstack-protector-strong"
-	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
-	help
-	  Like -fstack-protector but includes additional functions to be
-	  protected - those that have local array definitions, or have
-	  references to local frame addresses.
-
-comment "Stack Smashing Protection strong needs a toolchain w/ gcc >= 4.9"
-	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
-
-config BR2_SSP_ALL
-	bool "-fstack-protector-all"
-	help
-	  Like -fstack-protector except that all functions are
-	  protected. This option might have a significant performance
-	  impact on the compiled binaries.
-
-endchoice
-
-comment "Stack Smashing Protection needs a toolchain w/ SSP"
-	depends on !BR2_TOOLCHAIN_HAS_SSP
-
-choice
 	bool "libraries"
 	default BR2_SHARED_LIBS if BR2_BINFMT_SUPPORTS_SHARED
 	default BR2_STATIC_LIBS if !BR2_BINFMT_SUPPORTS_SHARED
@@ -728,6 +673,65 @@  config BR2_REPRODUCIBLE
 
 endmenu
 
+menu "Security Hardening Options"
+
+choice
+	bool "build code with Stack Smashing Protection"
+	default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
+	depends on BR2_TOOLCHAIN_HAS_SSP
+	help
+	  Enable stack smashing protection support using GCC's
+	  -fstack-protector option family.
+
+	  See
+	  http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt
+	  for details.
+
+	  Note that this requires the toolchain to have SSP support.
+	  This is always the case for glibc and eglibc toolchain, but is
+	  optional in uClibc toolchains.
+
+config BR2_SSP_NONE
+	bool "None"
+	help
+	  Disable stack-smashing protection.
+
+config BR2_SSP_REGULAR
+	bool "-fstack-protector"
+	help
+	  Emit extra code to check for buffer overflows, such as stack
+	  smashing attacks. This is done by adding a guard variable to
+	  functions with vulnerable objects. This includes functions
+	  that call alloca, and functions with buffers larger than 8
+	  bytes. The guards are initialized when a function is entered
+	  and then checked when the function exits. If a guard check
+	  fails, an error message is printed and the program exits.
+
+config BR2_SSP_STRONG
+	bool "-fstack-protector-strong"
+	depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
+	help
+	  Like -fstack-protector but includes additional functions to be
+	  protected - those that have local array definitions, or have
+	  references to local frame addresses.
+
+comment "Stack Smashing Protection strong needs a toolchain w/ gcc >= 4.9"
+	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_4_9
+
+config BR2_SSP_ALL
+	bool "-fstack-protector-all"
+	help
+	  Like -fstack-protector except that all functions are
+	  protected. This option might have a significant performance
+	  impact on the compiled binaries.
+
+endchoice
+
+comment "Stack Smashing Protection needs a toolchain w/ SSP"
+	depends on !BR2_TOOLCHAIN_HAS_SSP
+
+endmenu
+
 endmenu
 
 source "toolchain/Config.in"