Bug 15102

Summary:	Using overrides on security flags may produce an incorrect meta-environment for the generated SDK
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Mark Hatle <mark.hatle>
Component:	devtools / tool chain	Assignee:	Richard Purdie <richard.purdie>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Medium+	CC:	mark.hatle, meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie
Version:	4.1.4
Target Milestone:	6.2
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Mark Hatle 2023-04-13 17:20:28 UTC

I created a baremetal distribution file, and included:

SECURITY_CFLAGS:class-target ?= ""
SECURITY_LDFLAGS:class-target ?= ""

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc

Building my (class-target) recipes, all of the values are expected.  However when generating an SDK, the produced environment files included the security CFLAGS and LDFLAGS.

I built my SDK using 'bitbake meta-toolchain', this in-turn uses 'meta-environment' recipe to construct and populate the environment files.

It appears that meta-environment does not run in class-target context, so any overrides may be evaluated differently then a normal target recipe.  This may affect both the mandatory and options cflags and ldflags, producing an incompatible environment file to the binaries in the system.

OE baremetal configuration uses 'tclibc-baremetal' override, which likely is not present in the cross canadian contetext of meta-environemnt as well.

Comment 1 Richard Purdie 2023-04-14 15:55:06 UTC

My feeling is we may need to split meta-environment into two parts, one in target context and one in cross-canadian context since they can't access the right information of both contexts in one recipe.

Comment 2 Randy MacLeod 2023-04-20 14:32:48 UTC

Mark, can you work at this?

Comment 3 Mark Hatle 2023-04-20 16:57:23 UTC

I will continue to explore this, but at this point I'm not sure how to fix it.  Splitting the environments, as RP suggests is the probably the only reasonable way to deal with this -- but I'm not sure how to get the environments to split properly.

I am fine if you assign this to me, but I can't promise I'll get a fix in the short term.

Comment 4 Randy MacLeod 2023-04-20 18:53:45 UTC

Thanks Mark.