bitbake.conf: Add SECURITY_*FLAGS overridable definition
PATCH v2 1/2 bitbake.conf: Add SECURITY_*FLAGS overridable definition
This will allow for SECURITY_CFLAGS and SECURITY_LDFLAGS to be defined in the security_flags.inc and override the empty default.
--- meta/conf/bitbake.conf | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
meta/conf/bitbake.conf +4 -2
@@ -493,7 +493,8 @@ export TARGET_CPPFLAGS = "" export BUILD_CFLAGS = "${BUILD_CPPFLAGS} ${BUILD_OPTIMIZATION}" BUILDSDK_CFLAGS = "${BUILDSDK_CPPFLAGS} ${BUILD_OPTIMIZATION}" -export CFLAGS = "${TARGET_CFLAGS}" +SECURITY_CFLAGS ?= "" +export CFLAGS = "${TARGET_CFLAGS} ${SECURITY_CFLAGS}" export TARGET_CFLAGS = "${TARGET_CPPFLAGS} ${SELECTED_OPTIMIZATION}" export BUILD_CXXFLAGS = "${BUILD_CFLAGS} -fpermissive"
@@ -523,7 +524,8 @@ LINKER_HASH_STYLE_mips64 = "sysv" LINKER_HASH_STYLE_mips64el = "sysv" TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_STYLE', True) != 'gnu']}" -export LDFLAGS = "${TARGET_LDFLAGS}" +SECURITY_LDFLAGS ?= "" +export LDFLAGS = "${TARGET_LDFLAGS} ${SECURITY_LDFLAGS}" export TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE}" #export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${libdir} \ # -Wl,-rpath-link,${STAGING_DIR_TARGET}${libdir} \
Signature · 1 line
1.8.1.4
PATCH v2 2/2 security_flags: Add the compiler and linker flags that enhance security
These flags add addition checks at compile, link and runtime to prevent stack smashing, checking for buffer overflows, and link at program start to prevent call spoofing later.
This needs to be explicitly enabled by adding the following line to your local.conf:
require conf/distro/include/security_flags.inc
[YOCTO #3868]
--- meta/conf/distro/include/security_flags.inc | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 meta/conf/distro/include/security_flags.inc
meta/conf/distro/include/security_flags.inc new file +23 -0
@@ -0,0 +1,23 @@ +SECURITY_CFLAGS = "-fstack-protector-all -pie -fpie -D_FORTIFY_SOURCE=2" +SECURITY_LDFLAGS = "-Wl,-z,relro,-z,now" + +# Curl seems to check for FORTIFY_SOURCE in CFLAGS, but even assigned +# to CPPFLAGS it gets picked into CFLAGS in bitbake. +#TARGET_CPPFLAGS_pn-curl += "-D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-curl = "-fstack-protector-all -pie -fpie" +SECURITY_CFLAGS_pn-ppp = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-eglibc = "" +SECURITY_CFLAGS_pn-eglibc-initial = "" +SECURITY_CFLAGS_pn-zlib = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-gcc-runtime = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-libgcc = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-tcl = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-libcap = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-python-smartpm = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-python-imaging = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-python-pycurl = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-kexec-tools = "-fstack-protector-all -D_FORTIFY_SOURCE=2" + +# These 2 have text relco errors with the pie options enabled +SECURITY_CFLAGS_pn-pulseaudio = "-fstack-protector-all -D_FORTIFY_SOURCE=2" +SECURITY_CFLAGS_pn-ltp = "-fstack-protector-all -D_FORTIFY_SOURCE=2"
Signature · 1 line
1.8.1.4
Re: [PATCH 2/2 v2] security_flags: Add the compiler and linker flags that enhance security
Quoted 1 line · Saul Wold
+# These 2 have text relco errors with the pie options enabled
typo
Quoted 13 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.Signed-off-by Saul Wold <[email protected]>--- meta/conf/bitbake.conf | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0
meta/conf/bitbake.conf export TARGET_CPPFLAGS = "" · line 498
Quoted 7 lines
meta/conf/bitbake.conf +2
-1@@ -493,7 +493,8 @@ export TARGET_CPPFLAGS = "" export BUILD_CFLAGS = "${BUILD_CPPFLAGS} ${BUILD_OPTIMIZATION}" BUILDSDK_CFLAGS = "${BUILDSDK_CPPFLAGS} ${BUILD_OPTIMIZATION}" -export CFLAGS = "${TARGET_CFLAGS}" +SECURITY_CFLAGS ?= "" +export CFLAGS = "${TARGET_CFLAGS} ${SECURITY_CFLAGS}" export TARGET_CFLAGS = "${TARGET_CPPFLAGS} ${SELECTED_OPTIMIZATION}"
I would prefer if the cflags came in via the TARGET_CFLAGS, similar to how the selected_optimization works. In the past we've hacked around with CFLAGS itself and in the end it's always seem to have caused problems. By modifing TARGET_CFLAGS instead, then the user can do (in a recipe):
CFLAGS = "-fmy-custom-flag ${TARGET_CFLAGS}"
meta/conf/bitbake.conf LINKER_HASH_STYLE_mips64 = "sysv" · line 528
Quoted 8 lines
meta/conf/bitbake.conf +2
-1export BUILD_CXXFLAGS = "${BUILD_CFLAGS} -fpermissive"@@ -523,7 +524,8 @@ LINKER_HASH_STYLE_mips64 = "sysv" LINKER_HASH_STYLE_mips64el = "sysv" TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_STYLE', True) != 'gnu']}" -export LDFLAGS = "${TARGET_LDFLAGS}" +SECURITY_LDFLAGS ?= "" +export LDFLAGS = "${TARGET_LDFLAGS} ${SECURITY_LDFLAGS}"
Same comment here.
Quoted 4 lines
meta/conf/bitbake.conf +0
-0export TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE}" #export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${libdir} \ # -Wl,-rpath-link,${STAGING_DIR_TARGET}${libdir} \
Quoted 24 lines · Mark Hatle
Quoted 13 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.Signed-off-by Saul Wold <[email protected]>--- meta/conf/bitbake.conf | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)meta/conf/bitbake.conf +0
-0meta/conf/bitbake.conf export TARGET_CPPFLAGS = "" · line 498
Quoted 7 lines
meta/conf/bitbake.conf +2
-1@@ -493,7 +493,8 @@ export TARGET_CPPFLAGS = "" export BUILD_CFLAGS = "${BUILD_CPPFLAGS} ${BUILD_OPTIMIZATION}" BUILDSDK_CFLAGS = "${BUILDSDK_CPPFLAGS} ${BUILD_OPTIMIZATION}" -export CFLAGS = "${TARGET_CFLAGS}" +SECURITY_CFLAGS ?= "" +export CFLAGS = "${TARGET_CFLAGS} ${SECURITY_CFLAGS}" export TARGET_CFLAGS = "${TARGET_CPPFLAGS} ${SELECTED_OPTIMIZATION}"I would prefer if the cflags came in via the
TARGET_CFLAGS, similar to how theselected_optimizationworks. In the past we've hacked around with CFLAGS itself and in the end it's always seem to have caused problems. By modifingTARGET_CFLAGSinstead, then the user can do (in a recipe):
Quoted 1 line
CFLAGS = "-fmy-custom-flag ${TARGET_CFLAGS}"
yes infact it should be added via TARGET_CFLAGS
Quoted 21 lines
meta/conf/bitbake.conf LINKER_HASH_STYLE_mips64 = "sysv" · line 528
Quoted 9 lines
meta/conf/bitbake.conf +2
-1export BUILD_CXXFLAGS = "${BUILD_CFLAGS} -fpermissive"@@ -523,7 +524,8 @@ LINKER_HASH_STYLE_mips64 = "sysv" LINKER_HASH_STYLE_mips64el = "sysv" TARGET_LINK_HASH_STYLE ?= "${@['-Wl,--hash-style=gnu',''][d.getVar('LINKER_HASH_STYLE', True) != 'gnu']}" -export LDFLAGS = "${TARGET_LDFLAGS}" +SECURITY_LDFLAGS ?= "" +export LDFLAGS = "${TARGET_LDFLAGS} ${SECURITY_LDFLAGS}"Same comment here.
meta/conf/bitbake.conf LINKER_HASH_STYLE_mips64 = "sysv" · line 531
Quoted 4 lines
meta/conf/bitbake.conf +0
-0export TARGET_LDFLAGS = "-Wl,-O1 ${TARGET_LINK_HASH_STYLE}" #export TARGET_LDFLAGS = "-L${STAGING_DIR_TARGET}${libdir} \ # -Wl,-rpath-link,${STAGING_DIR_TARGET}${libdir} \_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 2 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.
Why can't security_flags.inc just append to CFLAGS and LDFLAGS respectively, or some other set of variables that already exists?
Creating new variables in bitbake.conf does have a cost in terms of parse time and memory footprint for every recipe. If the variables are referenced in ${CFLAGS} etc then it also adds an extra substitution whenever CFLAGS is expanded. The cost of those things isn't enormous, but it isn't zero either and adding them isn't something that we should do capriciously.
p.
Quoted 7 lines · Phil Blundell
Quoted 2 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.Why can't security_flags.inc just append to CFLAGS and LDFLAGS respectively, or some other set of variables that already exists?
So, if I remember correctly there was issues with this because there are a number of packages that have to modify specifically the security related flags (see the list in security_flags.inc), the ordering/timing of being able to due that correctly did not allow for setting it directly in CFLAGS or TARGET_CFLAGS.
Quoted 7 lines
Creating new variables in bitbake.conf does have a cost in terms of parse time and memory footprint for every recipe. If the variables are referenced in ${CFLAGS} etc then it also adds an extra substitution whenever CFLAGS is expanded. The cost of those things isn't enormous, but it isn't zero either and adding them isn't something that we should do capriciously.
I understand, and RP and I talked about this, we needed a separate variable to ensure the correct substitution occurred for those that needed to disable or remove certain flags.
Sau!
Quoted 5 lines
p.
Quoted 21 lines · Saul Wold
Quoted 7 lines · Phil Blundell
Quoted 2 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.Why can't security_flags.inc just append to CFLAGS and LDFLAGS respectively, or some other set of variables that already exists?
So, if I remember correctly there was issues with this because there are a number of packages that have to modify specifically the security related flags (see the list in security_flags.inc), the ordering/timing of being able to due that correctly did not allow for setting it directly in CFLAGS or
TARGET_CFLAGS.Quoted 7 lines
Creating new variables in bitbake.conf does have a cost in terms of parse time and memory footprint for every recipe. If the variables are referenced in ${CFLAGS} etc then it also adds an extra substitution whenever CFLAGS is expanded. The cost of those things isn't enormous, but it isn't zero either and adding them isn't something that we should do capriciously.
Quoted 3 lines
I understand, and RP and I talked about this, we needed a separate variable to ensure the correct substitution occurred for those that needed to disable or remove certain flags.
What RP said was that he'd prefer to see no bitbake.conf changes and to do this all in the .inc. We should have a variable like the SECURITY_FLAGS you have but this can also be appended in the .inc.
If we need to modify it on a per recipe basis we still then can so:
SECURITY_CFLAGS = "-fstack-protector-all -pie -fpie -D_FORTIFY_SOURCE=2" TARGET_CFLAGS_append = " ${SECURITY_CFLAGS}"
SECURITY_LDFLAGS = "-Wl,-z,relro,-z,now"TARGET_LDFLAGS_append = " ${SECURITY_LDFLAGS}"
all in the .inc. Or am I missing something?
Cheers,
Richard
Quoted 5 lines · Saul Wold
So, if I remember correctly there was issues with this because there are a number of packages that have to modify specifically the security related flags (see the list in security_flags.inc), the ordering/timing of being able to due that correctly did not allow for setting it directly in CFLAGS or
TARGET_CFLAGS.
What exactly were the issues? I can't think of any obvious reason why it wouldn't work for security.inc to do:
SECURITY_CFLAGS = "-fstack-protector-all -pie -fpie -D_FORTIFY_SOURCE=2" SECURITY_CFLAGS_pn-curl = "-fstack-protector-all -pie -fpie" CFLAGS += "${SECURITY_CFLAGS}"
p.
Quoted 7 lines · Phil Blundell
Quoted 5 lines · Saul Wold
So, if I remember correctly there was issues with this because there are a number of packages that have to modify specifically the security related flags (see the list in security_flags.inc), the ordering/timing of being able to due that correctly did not allow for setting it directly in CFLAGS or
TARGET_CFLAGS.
Quoted 7 lines
What exactly were the issues? I can't think of any obvious reason why it wouldn't work for security.inc to do:
SECURITY_CFLAGS= "-fstack-protector-all -pie -fpie -D_FORTIFY_SOURCE=2" SECURITY_CFLAGS_pn-curl = "-fstack-protector-all -pie -fpie" CFLAGS += "${SECURITY_CFLAGS}"
Seems either will work, this or TARGET_CFLAGS_append, I guess the problem I had in the past was trying to do it in the recipe or some other ordering problem. I think part of it is that these are special since they use "export"
So now the question is which place them TARGET_*FLAGS or *FLAGS??
TARGET_* makes it clear we are modifying those flags.
Sau!
Quoted 5 lines
p.
Quoted 9 lines · Saul Wold
Quoted 7 lines · Phil Blundell
Quoted 2 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.Why can't security_flags.inc just append to CFLAGS and LDFLAGS respectively, or some other set of variables that already exists?
So, if I remember correctly there was issues with this because there are a number of packages that have to modify specifically the security related flags (see the list in security_flags.inc), the ordering/timing of being able to due that correctly did not allow for setting it directly in CFLAGS or
TARGET_CFLAGS.
can you use append|prepend override ?
Quoted 22 lines
Quoted 8 lines
Creating new variables in bitbake.conf does have a cost in terms of parse time and memory footprint for every recipe. If the variables are referenced in ${CFLAGS} etc then it also adds an extra substitution whenever CFLAGS is expanded. The cost of those things isn't enormous, but it isn't zero either and adding them isn't something that we should do capriciously.
I understand, and RP and I talked about this, we needed a separate variable to ensure the correct substitution occurred for those that needed to disable or remove certain flags.
Sau!
Quoted 5 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 7 lines · Phil Blundell
Quoted 2 lines · Saul Wold
This will allow for
SECURITY_CFLAGSandSECURITY_LDFLAGSto be defined in the security_flags.inc and override the empty default.Why can't security_flags.inc just append to CFLAGS and LDFLAGS respectively, or some other set of variables that already exists?
It could help debugging metadata a bit if they are separate but appending to TARGET_FLAGS in this inc file is not as bad an option
Quoted 14 lines
Creating new variables in bitbake.conf does have a cost in terms of parse time and memory footprint for every recipe. If the variables are referenced in ${CFLAGS} etc then it also adds an extra substitution whenever CFLAGS is expanded. The cost of those things isn't enormous, but it isn't zero either and adding them isn't something that we should do capriciously.
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core