[OE-core] [PATCH 1/2 v2] bitbake.conf: Add SECURITY_*FLAGS overridable definition

[Richard Purdie]

On Fri, 2013-06-28 at 13:19 -0700, Saul Wold wrote:
> On 06/28/2013 12:51 PM, Phil Blundell wrote:
> > On Fri, 2013-06-28 at 12:23 -0700, Saul Wold wrote:
> >> This will allow for SECURITY_CFLAGS and SECURITY_LDFLAGS to 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.
> 
> > 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.

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