toolchain: set the ssp gcc option in kconfig
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/4 toolchain: set the ssp gcc option in kconfig
From: "Yann E. MORIN" <[email protected]>
Currently, we repeat all the SSP level selection deep down to the toolchain wrapper itself, where we eventually translate it to the actual SSP option to use. This is a bit redundant.
Additionally, we will want to check that the toolchain actually supports that option (for those toolchain where it was backported).
So, move the translation into kconfig.
Since that new option does have neither a prompt, nor a default value for SSP_NONE, it will not be set unless it actually contains a non-empty string, so it will never be "" and we can skip the usual qstrip-then-quote-anyway dance.
--- Config.in | 6 ++++++ toolchain/toolchain-wrapper.c | 10 ++-------- toolchain/toolchain-wrapper.mk | 8 ++------ 3 files changed, 10 insertions(+), 14 deletions(-)
Config.in +6 -0
@@ -764,6 +764,12 @@ config BR2_SSP_ALL endchoice +config BR2_SSP_OPTION + string + default "-fstack-protector" if BR2_SSP_REGULAR + default "-fstack-protector-strong" if BR2_SSP_STRONG + default "-fstack-protector-all" if BR2_SSP_ALL + comment "Stack Smashing Protection needs a toolchain w/ SSP" depends on !BR2_TOOLCHAIN_HAS_SSP
toolchain/toolchain-wrapper.c +2 -8
@@ -98,14 +98,8 @@ static char *predef_args[] = {#if defined(BR_MIPS_TARGET_BIG_ENDIAN ) || defined(BR_ARC_TARGET_BIG_ENDIAN ) "-EB",#endif -#ifdef BR_SSP_REGULAR - "-fstack-protector", -#endif -#ifdef BR_SSP_STRONG - "-fstack-protector-strong", -#endif -#ifdef BR_SSP_ALL - "-fstack-protector-all", +#ifdef BR_SSP_OPTION + BR_SSP_OPTION,#endif #ifdef BR_ADDITIONAL_CFLAGS BR_ADDITIONAL_CFLAGS
toolchain/toolchain-wrapper.mk +2 -6
@@ -51,12 +51,8 @@ else ifeq ($(BR2_RELRO_FULL),y) TOOLCHAIN_WRAPPER_ARGS += -DBR2_RELRO_FULL endif -ifeq ($(BR2_SSP_REGULAR),y) -TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_REGULAR -else ifeq ($(BR2_SSP_STRONG),y) -TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_STRONG -else ifeq ($(BR2_SSP_ALL),y) -TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_ALL +ifneq ($(BR2_SSP_OPTION),) +TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_OPTION='$(BR2_SSP_OPTION)' endif define TOOLCHAIN_WRAPPER_BUILD
Signature · 15 lines
2.17.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 1/4 toolchain: set the ssp gcc option in kconfig
On 11/03/2019 07:48, yann.morin at orange.com wrote:
[snip]
Quoted 7 lines
toolchain/toolchain-wrapper.mk +0
-0@@ -51,12 +51,8 @@ else ifeq ($(BR2_RELRO_FULL),y) TOOLCHAIN_WRAPPER_ARGS += -DBR2_RELRO_FULL endif
toolchain/toolchain-wrapper.mk else ifeq ($(BR2_RELRO_FULL),y) · line 56
Quoted 10 lines
toolchain/toolchain-wrapper.mk +2
-6-ifeq ($(BR2_SSP_REGULAR),y) -TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_REGULAR -else ifeq ($(BR2_SSP_STRONG),y) -TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_STRONG -else ifeq ($(BR2_SSP_ALL),y) -TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_ALL +ifneq ($(BR2_SSP_OPTION),) +TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_OPTION='$(BR2_SSP_OPTION)' endif
I try to mention this every time someone touches the toolchain wrapper:
I'd really like to use the BR_ADDITIONAL_CFLAGS instead, by changing the
definition in the .mk file to something like:
TOOLCHAIN_WRAPPER_OPTS = \
$(call qstrip,$(BR2_TARGET_OPTIMIZATION)) \
$(call qstrip,$(BR2_SSP_OPTION))TOOLCHAIN_WRAPPER_ARGS += \
-DBR_ADDITIONAL_CFLAGS='$(foreach f,$(TOOLCHAIN_WRAPPER_OPTS),"$(f)"$(comma))'
(note that I preferred the qstrip instead of the ifdef here, and adding quotes explicitly in the foreach, but you may want to implement it differently).
Regards,
Arnout
PATCH 1/4 toolchain: set the ssp gcc option in kconfig
Arnout, All,
On 2019-03-12 01:02 +0100, Arnout Vandecappelle spake thusly:
Quoted 2 lines · yann.morin at orange.com
[snip]
[--SNIP--]
Quoted 6 lines
toolchain/toolchain-wrapper.mk else ifeq ($(BR2_RELRO_FULL),y) · line 56
Quoted 3 lines
toolchain/toolchain-wrapper.mk +2
-0+ifneq ($(BR2_SSP_OPTION),) +TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_OPTION='$(BR2_SSP_OPTION)' endifI'd really like to use the
BR_ADDITIONAL_CFLAGSinstead, by changing the
definition in the .mk file to something like:
Quoted 6 lines
TOOLCHAIN_WRAPPER_OPTS = \ $(call qstrip,$(BR2_TARGET_OPTIMIZATION)) \ $(call qstrip,$(BR2_SSP_OPTION))
TOOLCHAIN_WRAPPER_ARGS+= \
-DBR_ADDITIONAL_CFLAGS='$(foreach f,$(TOOLCHAIN_WRAPPER_OPTS),"$(f)"$(comma))'
OK, will do.
Quoted 2 lines
(note that I preferred the qstrip instead of the ifdef here, and adding quotes explicitly in the foreach, but you may want to implement it differently).
Yeah, I tried to avoid the qstriop-then-strip-anyway dance, but it is indeed nicer the way you wrote it.
Thanks!
Regards,
Yann E. MORIN.
Signature · 21 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 1/4 toolchain: set the ssp gcc option in kconfig
Quoted 12 lines · yann.morin at orange.com
Arnout, All,
On 2019-03-12 01:02 +0100, Arnout Vandecappelle spake thusly:
Quoted 2 lines · yann.morin at orange.com
[snip]
[--SNIP--]
Quoted 6 lines
toolchain/toolchain-wrapper.mk else ifeq ($(BR2_RELRO_FULL),y) · line 56
Quoted 3 lines
toolchain/toolchain-wrapper.mk +2
-0+ifneq ($(BR2_SSP_OPTION),) +TOOLCHAIN_WRAPPER_ARGS += -DBR_SSP_OPTION='$(BR2_SSP_OPTION)' endifI'd really like to use the
BR_ADDITIONAL_CFLAGSinstead, by changing the
definition in the .mk file to something like:
Quoted 8 lines
Quoted 6 lines
TOOLCHAIN_WRAPPER_OPTS = \ $(call qstrip,$(BR2_TARGET_OPTIMIZATION)) \ $(call qstrip,$(BR2_SSP_OPTION))
TOOLCHAIN_WRAPPER_ARGS+= \
-DBR_ADDITIONAL_CFLAGS='$(foreach f,$(TOOLCHAIN_WRAPPER_OPTS),"$(f)"$(comma))'OK, will do.
Note that we don't have a runtime test for BR2_TRGET_OPTIMIZATION so some
manual testing will be needed.
Quoted 5 lines
Quoted 2 lines
(note that I preferred the qstrip instead of the ifdef here, and adding quotes explicitly in the foreach, but you may want to implement it differently).
Yeah, I tried to avoid the qstriop-then-strip-anyway dance, but it is indeed nicer the way you wrote it.
I like the qstrip-then-quote dance, because it makes things consistent.
Note that this is a very special case because we want to quote each
space-separated option here; in general we actually want to make sure the spaces are quoted when we do a qstrip-then-quote dance.
Regards,
Arnout
PATCH 2/4 toolchain: check the SSP option is known
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
Some toolchain vendors may have backported those options to older gcc versions, and we have no way to know, so we have to check that the user's selection is acceptable.
Extend the macro that currently checks for SSP in the toolchain, with a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted string, so we can safely and easily assign it to a shell variable to test and use it.
--- toolchain/helpers.mk | 8 ++++++++ toolchain/toolchain-external/pkg-toolchain-external.mk | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
toolchain/helpers.mk +8 -0
@@ -415,6 +415,7 @@ check_unusable_toolchain = \ # Check if the toolchain has SSP (stack smashing protector) support # # $1: cross-gcc path +# $2: gcc ssp option # check_toolchain_ssp = \ __CROSS_CC=$(strip $1) ; \
@@ -427,6 +428,13 @@ check_toolchain_ssp = \ echo "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \ exit 1 ; \ fi ; \ + __SSP_OPTION=$(2); \ + if [ -n "$${__SSP_OPTION}" ] ; then \ + if ! echo 'void main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \ + echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \ + exit 1 ; \ + fi; \ + fi; \ rm -f $(BUILD_DIR)/.br-toolchain-test.tmp* #
toolchain/toolchain-external/pkg-toolchain-external.mk +1 -1
@@ -549,7 +549,7 @@ define $(2)_CONFIGURE_CMDS else \ $$(call check_glibc,$$$${SYSROOT_DIR}) ; \ fi - $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC)) + $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION)) endef $(2)_TOOLCHAIN_WRAPPER_ARGS += $$(TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS)
Signature · 15 lines
2.17.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 2/4 toolchain: check the SSP option is known
Quoted 6 lines · yann.morin at orange.com
From: "Yann E. MORIN" <[email protected]>
Some toolchain vendors may have backported those options to older gcc versions, and we have no way to know, so we have to check that the user's selection is acceptable.
Quoted 6 lines
Extend the macro that currently checks for SSP in the toolchain, with a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted string, so we can safely and easily assign it to a shell variable to test and use it.
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)
without an actual check that stack-protector=strong really is available... Maybe we need BR2_TOOLCHAIN_HAS_SSP_STRONG after all?
Regards,
Arnout
Quoted 50 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Matt Weber <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>--- toolchain/helpers.mk | 8 ++++++++ toolchain/toolchain-external/pkg-toolchain-external.mk | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)toolchain/helpers.mk +8
-0@@ -415,6 +415,7 @@ check_unusable_toolchain = \ # Check if the toolchain has SSP (stack smashing protector) support # # $1: cross-gcc path +# $2: gcc ssp option # check_toolchain_ssp = \ __CROSS_CC=$(strip $1) ; \@@ -427,6 +428,13 @@ check_toolchain_ssp = \ echo "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \ exit 1 ; \ fi ; \ + __SSP_OPTION=$(2); \ + if [ -n "$${__SSP_OPTION}" ] ; then \ + if ! echo 'void main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \ + echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \ + exit 1 ; \ + fi; \ + fi; \ rm -f $(BUILD_DIR)/.br-toolchain-test.tmp* #toolchain/toolchain-external/pkg-toolchain-external.mk +1
-1@@ -549,7 +549,7 @@ define $(2)_CONFIGURE_CMDS else \ $$(call check_glibc,$$$${SYSROOT_DIR}) ; \ fi - $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC)) + $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION)) endef $(2)_TOOLCHAIN_WRAPPER_ARGS += $$(TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS)
PATCH 2/4 toolchain: check the SSP option is known
Arnout, All,
On 2019-03-12 01:25 +0100, Arnout Vandecappelle spake thusly:
Quoted 4 lines · yann.morin at orange.com
Quoted 3 lines
From: "Yann E. MORIN" <[email protected]>
Extend the macro that currently checks for SSP in the toolchain, with a new test that the actual SSP option is recognised and accepted.
[--SNIP--]
Quoted 3 lines
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)
It should probably be changed to: $(if $(BR2_SSP_STRONG),yes,no)
I'll check what vlc really wants it for (e.g. strong, all, regular?), fix and send a patch.
Quoted 2 lines
without an actual check that stack-protector=strong really is available... Maybe we need
BR2_TOOLCHAIN_HAS_SSP_STRONGafter all?
I really pondered doing it that way, but I decided against, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has SSP strong
- of the external pre-built toolchains, only the codesourcery-arm one has a gcc-4.8 which lacks SSP strong (and I use that in the cover letter to explain how to test my changes), all the others have a gcc >= 4.9
So, we'd have to add this _HAS_SSP_STRONG for a single case.
Now, the vlc case, fixed as I suggest above, would be covered by this configure-test.
Regards,
Yann E. MORIN.
Quoted 49 lines
Quoted 49 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Matt Weber <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>--- toolchain/helpers.mk | 8 ++++++++ toolchain/toolchain-external/pkg-toolchain-external.mk | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)toolchain/helpers.mk +8
-0@@ -415,6 +415,7 @@ check_unusable_toolchain = \ # Check if the toolchain has SSP (stack smashing protector) support # # $1: cross-gcc path +# $2: gcc ssp option # check_toolchain_ssp = \ __CROSS_CC=$(strip $1) ; \@@ -427,6 +428,13 @@ check_toolchain_ssp = \ echo "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \ exit 1 ; \ fi ; \ + __SSP_OPTION=$(2); \ + if [ -n "$${__SSP_OPTION}" ] ; then \ + if ! echo 'void main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \ + echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \ + exit 1 ; \ + fi; \ + fi; \ rm -f $(BUILD_DIR)/.br-toolchain-test.tmp* #toolchain/toolchain-external/pkg-toolchain-external.mk +1
-1@@ -549,7 +549,7 @@ define $(2)_CONFIGURE_CMDS else \ $$(call check_glibc,$$$${SYSROOT_DIR}) ; \ fi - $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC)) + $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION)) endef $(2)_TOOLCHAIN_WRAPPER_ARGS += $$(TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS)
Signature · 21 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 2/4 toolchain: check the SSP option is known
Quoted 25 lines · yann.morin at orange.com
Arnout, All,
On 2019-03-12 01:25 +0100, Arnout Vandecappelle spake thusly:
Quoted 4 lines · yann.morin at orange.com
Quoted 3 lines
From: "Yann E. MORIN" <[email protected]>
Extend the macro that currently checks for SSP in the toolchain, with a new test that the actual SSP option is recognised and accepted.[--SNIP--]
Quoted 3 lines
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)
It should probably be changed to: $(if $(BR2_SSP_STRONG),yes,no)
I'll check what vlc really wants it for (e.g. strong, all, regular?), fix and send a patch.
Quoted 2 lines
without an actual check that stack-protector=strong really is available... Maybe we need
BR2_TOOLCHAIN_HAS_SSP_STRONGafter all?I really pondered doing it that way, but I decided against, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has SSP strong
Quoted 6 lines
- of the external pre-built toolchains, only the codesourcery-arm one has a gcc-4.8 which lacks SSP strong (and I use that in the cover letter to explain how to test my changes), all the others have a gcc >= 4.9
So, we'd have to add this
_HAS_SSP_STRONGfor a single case.
Hm, somehow I missed that in your commit message :-P
Regards,
Arnout
Quoted 57 lines
Now, the vlc case, fixed as I suggest above, would be covered by this configure-test.
Regards,
Yann E. MORIN.Quoted 49 lines
Quoted 49 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Matt Weber <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>--- toolchain/helpers.mk | 8 ++++++++ toolchain/toolchain-external/pkg-toolchain-external.mk | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)toolchain/helpers.mk +8
-0@@ -415,6 +415,7 @@ check_unusable_toolchain = \ # Check if the toolchain has SSP (stack smashing protector) support # # $1: cross-gcc path +# $2: gcc ssp option # check_toolchain_ssp = \ __CROSS_CC=$(strip $1) ; \@@ -427,6 +428,13 @@ check_toolchain_ssp = \ echo "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \ exit 1 ; \ fi ; \ + __SSP_OPTION=$(2); \ + if [ -n "$${__SSP_OPTION}" ] ; then \ + if ! echo 'void main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \ + echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \ + exit 1 ; \ + fi; \ + fi; \ rm -f $(BUILD_DIR)/.br-toolchain-test.tmp* #toolchain/toolchain-external/pkg-toolchain-external.mk +1
-1@@ -549,7 +549,7 @@ define $(2)_CONFIGURE_CMDS else \ $$(call check_glibc,$$$${SYSROOT_DIR}) ; \ fi - $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC)) + $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION)) endef $(2)_TOOLCHAIN_WRAPPER_ARGS += $$(TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS)
PATCH 2/4 toolchain: check the SSP option is known
Arnout, All,
On 2019-03-12 09:53 +0100, Arnout Vandecappelle spake thusly:
Quoted 26 lines · yann.morin at orange.com
Quoted 25 lines
Arnout, All,
On 2019-03-12 01:25 +0100, Arnout Vandecappelle spake thusly:
Quoted 4 lines · yann.morin at orange.com
Quoted 3 lines
From: "Yann E. MORIN" <[email protected]>
Extend the macro that currently checks for SSP in the toolchain, with a new test that the actual SSP option is recognised and accepted.[--SNIP--]
Quoted 3 lines
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)
It should probably be changed to: $(if $(BR2_SSP_STRONG),yes,no)
I'll check what vlc really wants it for (e.g. strong, all, regular?), fix and send a patch.
Quoted 2 lines
without an actual check that stack-protector=strong really is available... Maybe we need
BR2_TOOLCHAIN_HAS_SSP_STRONGafter all?I really pondered doing it that way, but I decided against, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has SSP strong
Quoted 8 lines
Quoted 6 lines
- of the external pre-built toolchains, only the codesourcery-arm one has a gcc-4.8 which lacks SSP strong (and I use that in the cover letter to explain how to test my changes), all the others have a gcc >= 4.9
So, we'd have to add this
_HAS_SSP_STRONGfor a single case.Hm, somehow I missed that in your commit message :-P
ACK, I'll add it to the commit message before submitting v2.
Regards,
Yann E. MORIN.
Quoted 60 lines
Regards,
ArnoutQuoted 57 lines
Now, the vlc case, fixed as I suggest above, would be covered by this configure-test.
Regards,
Yann E. MORIN.Quoted 49 lines
Quoted 49 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Matt Weber <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>--- toolchain/helpers.mk | 8 ++++++++ toolchain/toolchain-external/pkg-toolchain-external.mk | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)toolchain/helpers.mk +8
-0@@ -415,6 +415,7 @@ check_unusable_toolchain = \ # Check if the toolchain has SSP (stack smashing protector) support # # $1: cross-gcc path +# $2: gcc ssp option # check_toolchain_ssp = \ __CROSS_CC=$(strip $1) ; \@@ -427,6 +428,13 @@ check_toolchain_ssp = \ echo "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" ; \ exit 1 ; \ fi ; \ + __SSP_OPTION=$(2); \ + if [ -n "$${__SSP_OPTION}" ] ; then \ + if ! echo 'void main(){}' | $${__CROSS_CC} -Werror $${__SSP_OPTION} -x c - -o $(BUILD_DIR)/.br-toolchain-test.tmp >/dev/null 2>&1 ; then \ + echo "SSP option $${__SSP_OPTION} not available in this toolchain, please select another SSP level" ; \ + exit 1 ; \ + fi; \ + fi; \ rm -f $(BUILD_DIR)/.br-toolchain-test.tmp* #toolchain/toolchain-external/pkg-toolchain-external.mk +1
-1@@ -549,7 +549,7 @@ define $(2)_CONFIGURE_CMDS else \ $$(call check_glibc,$$$${SYSROOT_DIR}) ; \ fi - $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC)) + $$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION)) endef $(2)_TOOLCHAIN_WRAPPER_ARGS += $$(TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS)
Signature · 21 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
A message that is not in the archive (sent off-list or not yet received): 20190312061810.GB4924@r-lnx-nyma7486-2
PATCH 2/4 toolchain: check the SSP option is known
Arnout, All,
On 2019-03-12 07:18 +0100, MORIN Yann TGI/OLS spake thusly:
Quoted 1 line
On 2019-03-12 01:25 +0100, Arnout Vandecappelle spake thusly:
[--SNIP--]
Quoted 4 lines
Quoted 2 lines
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)I'll check what vlc really wants it for (e.g. strong, all, regular?), fix and send a patch.
So, vlc already depends on gcc >= 4.9 anyway, so there will always have support for fstack-protctor-strong, and this legacy wart can be removed now, I guess.
I'll send the patch.
Regards,
Yann E. MORIN.
Signature · 21 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 2/4 toolchain: check the SSP option is known
Quoted 5 lines · yann.morin at orange.com
Arnout, All,
On 2019-03-12 07:18 +0100, MORIN Yann TGI/OLS spake thusly:
Quoted 1 line
On 2019-03-12 01:25 +0100, Arnout Vandecappelle spake thusly:
[--SNIP--]
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)I'll check what vlc really wants it for (e.g. strong, all, regular?), fix and send a patch.
So, vlc already depends on gcc >= 4.9 anyway, so there will always have support for fstack-protctor-strong, and this legacy wart can be removed now, I guess.
Not at all! gcc >= 4.9 doesn't guarantee SSP availability, only that if SSP is
available, then -fstack-protector=strong will work. So the check is correct because vlc depends on gcc >= 4.9.
Regards,
Arnout
PATCH 2/4 toolchain: check the SSP option is known
Arnout, All,
On 2019-03-12 09:49 +0100, Arnout Vandecappelle spake thusly:
Quoted 11 lines · yann.morin at orange.com
Quoted 10 lines
Arnout, All,
On 2019-03-12 07:18 +0100, MORIN Yann TGI/OLS spake thusly:
Quoted 1 line
On 2019-03-12 01:25 +0100, Arnout Vandecappelle spake thusly:
[--SNIP--]
Quoted 4 lines
Quoted 2 lines
I notice that in vlc.mk, we have
ax_cv_check_cflags___fstack_protector_strong=$(if $(BR2_TOOLCHAIN_HAS_SSP),yes,no)I'll check what vlc really wants it for (e.g. strong, all, regular?), fix and send a patch.
Quoted 7 lines
Quoted 3 lines
So, vlc already depends on gcc >= 4.9 anyway, so there will always have support for fstack-protctor-strong, and this legacy wart can be removed now, I guess.
Not at all! gcc >= 4.9 doesn't guarantee SSP availability, only that if SSP is
available, then -fstack-protector=strong will work. So the check is correct because vlc depends on gcc >= 4.9.
Ah, yes, I see now. That's because SSP is a shared feature between the compiler and the C library, right?
So that check does indeed make sense as it is, even though it is not really obvious...
Thanks!
Regards,
Yann E. MORIN.
Signature · 21 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 3/4 toolchain: -fstack-protector-strong can be back-ported
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
Currently, use of -fstack-protector-strong is only available for gcc starting with 4.9, on the assumption that it appeared with that version.
Although this is true, it happens that quite a few vendors will have back-ported -fstack-protector-strong to older gcc versions (at least 4.8 seen in the wild).
Remove the guard against gcc>=4.9, and expand the help text.
---
Notes:
We could have changed the guard to something like:
depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9 || BR2_TOOLCHAIN_EXTERNAL
However, the latest gcc we support in the internal toolchain *is* gcc-4.9, so the condition would have always been true. Hence, we just drop the condition.
--- Config.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Config.in +3 -3
@@ -746,14 +746,14 @@ config BR2_SSP_REGULAR 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 + -fstack-protector-strong officially appeared in gcc 4.9, but + some vendors have backported -fstack-protector-strong to older + versions of gcc. config BR2_SSP_ALL bool "-fstack-protector-all"
Signature · 15 lines
2.17.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 4/4 toolchain: allow PIC/PIE without RELRO
In reply to a message not in the archiveFrom: "Yann E. MORIN" <[email protected]>
In commit 7484c1c3b806 (toolchain/toolchain-wrapper: add BR2_RELRO_), we added the PIC/PIE flags, but based on the RELRO_FULL condition.
It is however totally possible to do a PIC/PIE executable without RELRO_FULL, as it is also valid to do a PIC/PIE build with RELRO_PARTIAL.
Add a new option that now governs the PIC/PIE flags.
Note: it is unknown if RELRO_FULL really needs PIC/PIE or not, so we keep the current situation, where RELRO-FULL forces PIC/PIE compilation.
--- Config.in | 8 ++++++++ toolchain/toolchain-wrapper.c | 2 +- toolchain/toolchain-wrapper.mk | 4 ++++ 3 files changed, 13 insertions(+), 1 deletion(-)
Config.in +8 -0
@@ -712,6 +712,13 @@ endmenu comment "Security Hardening Options" +config BR2_PIC_PIE + bool "Build code with PIC/PIE" + depends on BR2_SHARED_LIBS + help + Generate Position-Independent Code (PIC) and link + Position-Independent Executables (PIE). + choice bool "Stack Smashing Protection" default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy
@@ -794,6 +801,7 @@ config BR2_RELRO_PARTIAL config BR2_RELRO_FULL bool "Full" + select BR2_PIC_PIE help This option includes the partial configuration, but also marks the GOT as read-only at the cost of initialization time during
toolchain/toolchain-wrapper.c +1 -1
@@ -370,7 +370,7 @@ int main(int argc, char **argv) *cur++ ="-Wno-builtin-macro-redefined" ; } -#ifdef BR2_RELRO_FULL +#ifdef BR2_PIC_PIE /* Patterned after Fedora/Gentoo hardening approaches. * https://fedoraproject.org/wiki/Changes/Harden_All_Packages * https://wiki.gentoo.org/wiki/Hardened/Toolchain#Position_Independent_Executables_.28PIEs.29
toolchain/toolchain-wrapper.mk +4 -0
@@ -45,6 +45,10 @@ ifeq ($(BR2_CCACHE_USE_BASEDIR),y) TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_BASEDIR='"$(BASE_DIR)"' endif +ifeq ($(BR2_PIC_PIE),y) +TOOLCHAIN_WRAPPER_ARGS += -DBR2_PIC_PIE +endif + ifeq ($(BR2_RELRO_PARTIAL),y) TOOLCHAIN_WRAPPER_ARGS += -DBR2_RELRO_PARTIAL else ifeq ($(BR2_RELRO_FULL),y)
Signature · 15 lines
2.17.1 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 4/4 toolchain: allow PIC/PIE without RELRO
Quoted 5 lines · yann.morin at orange.com
From: "Yann E. MORIN" <[email protected]>
In commit
7484c1c3b806(toolchain/toolchain-wrapper: addBR2_RELRO_), we added the PIC/PIE flags, but based on theRELRO_FULLcondition.
Quoted 7 lines
It is however totally possible to do a PIC/PIE executable without
RELRO_FULL, as it is also valid to do a PIC/PIE build withRELRO_PARTIAL.Add a new option that now governs the PIC/PIE flags.
Note: it is unknown if
RELRO_FULLreally needs PIC/PIE or not, so we keep the current situation, where RELRO-FULL forces PIC/PIE compilation.
I just checked on my host, and a simple test program compiled with -no-pie
-Wl,-z,relro -Wl,-z,now does work, so indeed the two seem to be independent.
I guess it's historical accident that the global full relro and PIE are
typically introduced together. From what I understand, they are pretty much independent.
Regards,
Arnout
Quoted 66 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Matt Weber <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>--- Config.in | 8 ++++++++ toolchain/toolchain-wrapper.c | 2 +- toolchain/toolchain-wrapper.mk | 4 ++++ 3 files changed, 13 insertions(+), 1 deletion(-)Config.in +8
-0@@ -712,6 +712,13 @@ endmenu comment "Security Hardening Options" +config BR2_PIC_PIE + bool "Build code with PIC/PIE" + depends on BR2_SHARED_LIBS + help + Generate Position-Independent Code (PIC) and link + Position-Independent Executables (PIE). + choice bool "Stack Smashing Protection" default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy@@ -794,6 +801,7 @@ config BR2_RELRO_PARTIAL config BR2_RELRO_FULL bool "Full" + select BR2_PIC_PIE help This option includes the partial configuration, but also marks the GOT as read-only at the cost of initialization time duringtoolchain/toolchain-wrapper.c +1
-1@@ -370,7 +370,7 @@ int main(int argc, char **argv) *cur++ ="-Wno-builtin-macro-redefined" ; } -#ifdef BR2_RELRO_FULL +#ifdef BR2_PIC_PIE /* Patterned after Fedora/Gentoo hardening approaches. * https://fedoraproject.org/wiki/Changes/Harden_All_Packages * https://wiki.gentoo.org/wiki/Hardened/Toolchain#Position_Independent_Executables_.28PIEs.29 toolchain/toolchain-wrapper.mk +4
-0@@ -45,6 +45,10 @@ ifeq ($(BR2_CCACHE_USE_BASEDIR),y) TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_BASEDIR='"$(BASE_DIR)"' endif +ifeq ($(BR2_PIC_PIE),y) +TOOLCHAIN_WRAPPER_ARGS += -DBR2_PIC_PIE +endif + ifeq ($(BR2_RELRO_PARTIAL),y) TOOLCHAIN_WRAPPER_ARGS += -DBR2_RELRO_PARTIAL else ifeq ($(BR2_RELRO_FULL),y)
PATCH 4/4 toolchain: allow PIC/PIE without RELRO
Arnout, All,
On 2019-03-12 01:36 +0100, Arnout Vandecappelle spake thusly:
Quoted 8 lines · yann.morin at orange.com
Quoted 4 lines
From: "Yann E. MORIN" <[email protected]>
Note: it is unknown if
RELRO_FULLreally needs PIC/PIE or not, so we keep the current situation, where RELRO-FULL forces PIC/PIE compilation.I just checked on my host, and a simple test program compiled with -no-pie
-Wl,-z,relro -Wl,-z,now does work, so indeed the two seem to be independent.
Still, I'd prefer tokeep the select to keep the current behaviour. We can drop it later on if someone has a need for it.
Quoted 3 lines
I guess it's historical accident that the global full relro and PIE are
typically introduced together. From what I understand, they are pretty much independent.
I talked with Matt on IRC about this the other day, and his reasoning for doing so as it is was to mimick the way done on distros (Debian, FC?), so it is not a complete accident either. ;-)
Regards,
Yann E. MORIN.
Quoted 69 lines
Regards,
ArnoutQuoted 66 lines
Signed-off-by "Yann E. MORIN" <[email protected]>Cc Matt Weber <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Thomas De Schampheleire <[email protected]>--- Config.in | 8 ++++++++ toolchain/toolchain-wrapper.c | 2 +- toolchain/toolchain-wrapper.mk | 4 ++++ 3 files changed, 13 insertions(+), 1 deletion(-)Config.in +8
-0@@ -712,6 +712,13 @@ endmenu comment "Security Hardening Options" +config BR2_PIC_PIE + bool "Build code with PIC/PIE" + depends on BR2_SHARED_LIBS + help + Generate Position-Independent Code (PIC) and link + Position-Independent Executables (PIE). + choice bool "Stack Smashing Protection" default BR2_SSP_ALL if BR2_ENABLE_SSP # legacy@@ -794,6 +801,7 @@ config BR2_RELRO_PARTIAL config BR2_RELRO_FULL bool "Full" + select BR2_PIC_PIE help This option includes the partial configuration, but also marks the GOT as read-only at the cost of initialization time duringtoolchain/toolchain-wrapper.c +1
-1@@ -370,7 +370,7 @@ int main(int argc, char **argv) *cur++ ="-Wno-builtin-macro-redefined" ; } -#ifdef BR2_RELRO_FULL +#ifdef BR2_PIC_PIE /* Patterned after Fedora/Gentoo hardening approaches. * https://fedoraproject.org/wiki/Changes/Harden_All_Packages * https://wiki.gentoo.org/wiki/Hardened/Toolchain#Position_Independent_Executables_.28PIEs.29 toolchain/toolchain-wrapper.mk +4
-0@@ -45,6 +45,10 @@ ifeq ($(BR2_CCACHE_USE_BASEDIR),y) TOOLCHAIN_WRAPPER_ARGS += -DBR_CCACHE_BASEDIR='"$(BASE_DIR)"' endif +ifeq ($(BR2_PIC_PIE),y) +TOOLCHAIN_WRAPPER_ARGS += -DBR2_PIC_PIE +endif + ifeq ($(BR2_RELRO_PARTIAL),y) TOOLCHAIN_WRAPPER_ARGS += -DBR2_RELRO_PARTIAL else ifeq ($(BR2_RELRO_FULL),y)
Signature · 21 lines
____________ .-----------------.--------------------: _ :------------------. | Yann E. MORIN | Real-Time Embedded | __/ ) | /"\ ASCII RIBBON | | +33 534.541.179 | Software Designer | _/ - /' | \ / CAMPAIGN | | +33 638.411.245 '--------------------: (_ `--, | X AGAINST | | yann.morin (at) orange.com |_=" ,--' | / \ HTML MAIL | '--------------------------------------:______/_____:------------------' _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
PATCH 4/4 toolchain: allow PIC/PIE without RELRO
Quoted 15 lines · yann.morin at orange.com
Arnout, All,
On 2019-03-12 01:36 +0100, Arnout Vandecappelle spake thusly:
Quoted 8 lines · yann.morin at orange.com
Quoted 4 lines
From: "Yann E. MORIN" <[email protected]>
Note: it is unknown if
RELRO_FULLreally needs PIC/PIE or not, so we keep the current situation, where RELRO-FULL forces PIC/PIE compilation.I just checked on my host, and a simple test program compiled with -no-pie
-Wl,-z,relro -Wl,-z,now does work, so indeed the two seem to be independent.Still, I'd prefer tokeep the select to keep the current behaviour. We can drop it later on if someone has a need for it.
Quoted 7 lines
Quoted 3 lines
I guess it's historical accident that the global full relro and PIE are
typically introduced together. From what I understand, they are pretty much independent.I talked with Matt on IRC about this the other day, and his reasoning for doing so as it is was to mimick the way done on distros (Debian, FC?), so it is not a complete accident either. ;-)
That's what I meant: it's historical accident that Fedora [1] and Debian [2]
started enabling -z,now and -pie at the same time. On their respective wiki pages that discuss enabling these things, they are in fact treated separately.
Regards,
Arnout
[1] https://fedoraproject.org/wiki/Security_Features_Matrix#Userspace_Hardening
[2] https://wiki.debian.org/Hardening#User_Space
PATCH 4/4 toolchain: allow PIC/PIE without RELRO
All,
Quoted 23 lines · Arnout Vandecappelle
Quoted 19 lines · yann.morin at orange.com
Arnout, All,
On 2019-03-12 01:36 +0100, Arnout Vandecappelle spake thusly:
Quoted 8 lines · yann.morin at orange.com
Quoted 4 lines
From: "Yann E. MORIN" <[email protected]>
Note: it is unknown if
RELRO_FULLreally needs PIC/PIE or not, so we keep the current situation, where RELRO-FULL forces PIC/PIE compilation.I just checked on my host, and a simple test program compiled with -no-pie
-Wl,-z,relro -Wl,-z,now does work, so indeed the two seem to be independent.Still, I'd prefer tokeep the select to keep the current behaviour. We can drop it later on if someone has a need for it.
Quoted 3 lines
I guess it's historical accident that the global full relro and PIE are
typically introduced together. From what I understand, they are pretty much independent.
Quoted 8 lines
Quoted 3 lines
I talked with Matt on IRC about this the other day, and his reasoning for doing so as it is was to mimick the way done on distros (Debian, FC?), so it is not a complete accident either. ;-)
That's what I meant: it's historical accident that Fedora [1] and Debian [2]
started enabling -z,now and -pie at the same time. On their respective wiki pages that discuss enabling these things, they are in fact treated separately.
Yep, sent a note on the v2 patch. I think we should drop the PIC/PIE select from RELRO FULL....
Quoted 9 lines
Regards,
Arnout[1] https://fedoraproject.org/wiki/Security_Features_Matrix#Userspace_Hardening
[2] https://wiki.debian.org/Hardening#User_Space
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 23 lines
Matthew Weber | Pr. Software Engineer | Commercial Avionics COLLINS AEROSPACE 400 Collins Road NE, Cedar Rapids, Iowa 52498, USA Tel: +1 319 295 7349 | FAX: +1 319 263 6099 matthew.weber at collins.com | collinsaerospace.com CONFIDENTIALITY WARNING: This message may contain proprietary and/or privileged information of Collins Aerospace and its affiliated companies. If you are not the intended recipient, please 1) Do not disclose, copy, distribute or use this message or its contents. 2) Advise the sender by return email. 3) Delete all copies (including all attachments) from your computer. Your cooperation is greatly appreciated. Any export restricted material should be shared using my matthew.weber at corp.rockwellcollins.com address.