blocking pie in recipes that build shared object files

blocking pie in recipes that build shared object files

[Peter A. Bigot]

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

Re: blocking pie in recipes that build shared object files

[Khem Raj]

On 14-08-04 09:56:37, Peter A. Bigot wrote:
> 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?

may be add SECURITY_CFLAGS_pn-blah = "${SECURITY_NO_PIE_CFLAGS}"
to layer.conf of given layer where recipe resides

Re: blocking pie in recipes that build shared object files

[Peter A. Bigot]

On 08/04/2014 05:39 PM, Khem Raj wrote:
> On 14-08-04 09:56:37, Peter A. Bigot wrote:
>> 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?
> 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

Re: blocking pie in recipes that build shared object files

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]

On Tuesday, August 5, 2014, Peter A. Bigot <pab@pabigot.com> wrote:

> On 08/04/2014 05:39 PM, Khem Raj wrote:
>
>> On 14-08-04 09:56:37, Peter A. Bigot wrote:
>>
>>> 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?
>>>
>> 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.

>
> 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 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
> future we need guidance on how to make recipes/layers compatible with
> distros that want to enable security_flags.inc.


> Peter
>

[-- Attachment #2: Type: text/html, Size: 3759 bytes --]