Re: [OE-core] Question about security_flags.inc and CC_ARCH

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Fri, 2021-01-15 at 13:46 +0000, Michael Ho wrote:
> I wanted to get a bit more understanding of why security_flags.inc
> tweaks CC_ARCH instead of CFLAGS.
>  
> Some developers who consume an SDK we produce using Yocto noticed
> that CC and
> CXX has FORTIFY_SOURCE embedded in the variables. These developers
> sometimes
> want to compile software in the SDK with compiler optimisations
> turned off in order
> to run code coverage tools like gcov. Typically they drop
> CFLAGS/CXXFLAGS in order
> to do this but they noted that with the SDK they also have to
> manually tweak CC/CXX
> to remove the FORTIFY_SOURCE references (because compilation fails
> without
> optimisation flags when using FORTIFY_SOURCE).
>  
> This comes from:
> https://patchwork.openembedded.org/patch/167198/ and
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6733a7873ca121295a2e309a6915b9816e1ae36b
>  
> I would’ve expected actually that FORTIFY_SOURCE bundles itself with
> CFLAGS/CXXFLAGS as it is dependent on being with the compiler
> optimisations. This is also how the Debian hardening wiki seems to
> describe it used [1].
>  
> I am guessing that this is moved to CC_ARCH to ensure FORTIFY_SOURCE
> is being enforced around the build system in case components are
> skipping out on CFLAGS and CXXFLAGS. Is that right?

In theory we should be giving an error if CFLAGS or LDFLAGS aren't
being used to compile our output. You're right that we probably don't
detect every case though and that was probably why we did that. I don't
really remember though. Khem might remember more, I suspect he'd have
done that for a reason.
 
> Would there be some objection to moving the security flags to
> CFLAGS/CXXFLAGS for the cross-canadian target (sdk)?

Yes, I'm fairly against people getting a different view of the flags in
the SDK compared to the main build environment, that just creates a
different set of problems unfortunately.

Cheers,

Richard