blocking pie in recipes that build shared object files
I've now hit two recipes in meta-openembedded that fail on armv7-a because SECURITY_CFLAGS has -pie as an option that leaks into a link command building a shared object file. This produces:
| /prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone/usr/lib/Scrt1.o: In function `_start': | /prj/oe/omap/build-beaglebone-master/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/eglibc/2.19-r0/eglibc-2.19/libc/csu/../ports/sysdeps/arm/start.S:128: undefined reference to `main' | collect2: error: ld returned 1 exit status | error: command 'arm-poky-linux-gnueabi-gcc' failed with exit status 1
In openembedded-core meta/conf/distro/include/security_flags.inc provides a bunch of package-specific overrides to use SECURITY_NO_PIE_CFLAGS for this sort of package.
It's not clear to me how that should be accomplished for recipes that are not part of openembedded-core. For http://patches.openembedded.org/patch/77165/ for python-smbus in meta-python I chose to override it in the bb file.
What is the best-practices solution to this problem?
Peter
Quoted 16 lines · Peter A. Bigot
I've now hit two recipes in meta-openembedded that fail on armv7-a because
SECURITY_CFLAGShas -pie as an option that leaks into a link command building a shared object file. This produces:|
/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone/usr/lib/Scrt1.o:
In function `_start':
| /prj/oe/omap/build-beaglebone-master/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/eglibc/2.19-r0/eglibc-2.19/libc/csu/../ports/sysdeps/arm/start.S:128:
undefined reference to `main'
| collect2: error: ld returned 1 exit status
| error: command 'arm-poky-linux-gnueabi-gcc' failed with exit status 1In openembedded-core meta/conf/distro/include/security_flags.inc provides a bunch of package-specific overrides to use
SECURITY_NO_PIE_CFLAGSfor this sort of package.
Quoted 6 lines
It's not clear to me how that should be accomplished for recipes that are not part of openembedded-core. For
http://patches.openembedded.org/patch/77165/ for python-smbus in meta-python I chose to override it in the bb file.What is the best-practices solution to this problem?
may be add SECURITY_CFLAGS_pn-blah = "${SECURITY_NO_PIE_CFLAGS}" to layer.conf of given layer where recipe resides
Quoted 17 lines · Khem Raj
Quoted 16 lines · Peter A. Bigot
I've now hit two recipes in meta-openembedded that fail on armv7-a because
SECURITY_CFLAGShas -pie as an option that leaks into a link command building a shared object file. This produces:|
/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone/usr/lib/Scrt1.o:
In function `_start':
| /prj/oe/omap/build-beaglebone-master/tmp/work/cortexa8hf-vfp-neon-poky-linux-gnueabi/eglibc/2.19-r0/eglibc-2.19/libc/csu/../ports/sysdeps/arm/start.S:128:
undefined reference to `main'
| collect2: error: ld returned 1 exit status
| error: command 'arm-poky-linux-gnueabi-gcc' failed with exit status 1In openembedded-core meta/conf/distro/include/security_flags.inc provides a bunch of package-specific overrides to use
SECURITY_NO_PIE_CFLAGSfor this sort of package.
Quoted 8 lines
Quoted 6 lines
It's not clear to me how that should be accomplished for recipes that are not part of openembedded-core. For
http://patches.openembedded.org/patch/77165/ for python-smbus in meta-python I chose to override it in the bb file.What is the best-practices solution to this problem?
may be add SECURITY_CFLAGS_pn-blah = "${SECURITY_NO_PIE_CFLAGS}" to layer.conf of given layer where recipe resides
Could do that. Is there precedent?
Looking into this more, the reason I'm hitting this is I'm using DISTRO=poky-lsb, which gives me oe-core's conf/distro/include/security_flags.inc automatically.
Now that I know more I'm uncomfortable about putting a distro-specific workaround in each recipe patch I submit, and more uncomfortable about creating new precedent by putting distro-specific workarounds in layer.conf files. Updates to python-smbus in meta-python and rrdtool in meta-oe are affected by this, plus the 42 package exceptions already listed in security_flags.inc.
I'm going to stop using poky-lsb for now to hide the problem, but for the future we need guidance on how to make recipes/layers compatible with distros that want to enable security_flags.inc.
Peter
Quoted 32 lines · Peter A. Bigot
Quoted 30 lines · Khem Raj
Quoted 28 lines · Peter A. Bigot
I've now hit two recipes in meta-openembedded that fail on armv7-a because
SECURITY_CFLAGShas -pie as an option that leaks into a link command building a shared object file. This produces:|
/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone/usr/lib/Scrt1.o:
In function `_start':
| /prj/oe/omap/build-beaglebone-master/tmp/work/cortexa8hf- vfp-neon-poky-linux-gnueabi/eglibc/2.19-r0/eglibc-2.19/libc/csu/../ports/sysdeps/arm/start.S:128:
undefined reference to `main'
| collect2: error: ld returned 1 exit status
| error: command 'arm-poky-linux-gnueabi-gcc' failed with exit status 1In openembedded-core meta/conf/distro/include/security_flags.inc provides a
bunch of package-specific overrides to useSECURITY_NO_PIE_CFLAGSfor this
sort of package.It's not clear to me how that should be accomplished for recipes that are not part of openembedded-core. For
http://patches.openembedded.org/patch/77165/ for python-smbus in meta-python
I chose to override it in the bb file.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
What is the best-practices solution to this problem?
may be add SECURITY_CFLAGS_pn-blah = "${SECURITY_NO_PIE_CFLAGS}" to layer.conf of given layer where recipe resides
Could do that. Is there precedent?
Don't think so. But you can compare to things like how package blacklisting is done in meta-OE.
Quoted 5 lines
Looking into this more, the reason I'm hitting this is I'm using DISTRO=poky-lsb, which gives me oe-core's conf/distro/include/security_flags.inc automatically.
Quoted 8 lines
Now that I know more I'm uncomfortable about putting a distro-specific workaround in each recipe patch I submit, and more uncomfortable about creating new precedent by putting distro-specific workarounds in layer.conf files. Updates to python-smbus in meta-python and rrdtool in meta-oe are affected by this, plus the 42 package exceptions already listed in security_flags.inc.
I don't think it's so distro related. Security flags is a general OE feature. So layers have to deal with it in distro independent way and IMO it's best place to dictate what recipes in a given layer can support, you can also add this to recipe itself and if numbers of recipes to deal with are less. It's similar to blacklisting feature.
I'm going to stop using poky-lsb for now to hide the problem, but for the
Quoted 6 lines
future we need guidance on how to make recipes/layers compatible with distros that want to enable security_flags.inc.
Peter