Question about security_flags.inc and CC_ARCH

Question about security_flags.inc and CC_ARCH

[Michael Ho]

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

Hi all,

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?

Would there be some objection to moving the security flags to CFLAGS/CXXFLAGS
for the cross-canadian target (sdk)?

Thanks for any insights people can share!

Kind regards,
Michael Ho

[1] https://wiki.debian.org/Hardening#Using_Hardening_Options

----------------------------------------------------------------------------------------------------

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung – Build and Release Engineering
Lise-Meitner-Straße 14
89081 Ulm

Tel.: ­+49-731-37804-071
Mobil: +49-152-54980-471
Fax: +49-731-37804-001
Mail: michael.ho@bmw-carit.de<mailto:michael.ho@bmw-carit.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit und Michael Böttrich
Sitz und Registergericht: München HRB 134810
-------------------------------------------------------------------------


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

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

[Richard Purdie]

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

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

[Joshua Watt]

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


On 1/15/21 10:05 AM, Richard Purdie wrote:
> 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.

FWIW, I've always veiwed it as things in CC_ARCH (which is rolled into 
$CC in the SDK) are flags you *must* have for the code to run on the 
platform (e.g. -march, API related things, etc.). Stuff in CFLAGS is 
stuff you probably want, but the program will still run if you don't use 
them. For the most part, this has been true, with SECURITY_FLAGS being 
the only recent notable exception.

We unfortunately do have cases were we disregard CFLAGS and use our own, 
but the compiled programs have still run on the platform.

>   
>> 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
>
>
>
>
> 
>

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

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

[Khem Raj]

On Fri, Jan 15, 2021 at 8:05 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> 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.

many packages don't use these flags ( -fPIE etc. ) directly but the
toolchain is automatically
configured to use them, which means their configure tests etc. get
them without considering
cflags, whereas for us where we want to accommodate external
toolchains which may not have
these options compiled-in etc we add them externally via cmdline and
best place for us to do
so is the CC itself since thats whats used by these configure checks.

Ideally, we should perhaps just change the toolchain to have these
defaults perhaps controlled via buildtime knobs
controlled via distro feature.

>
> > 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
>
>
>

Re: Question about security_flags.inc and CC_ARCH

[Michael Ho]

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

Hi,

Thanks for the info/comments. It's clear that it wouldn't be wise to differ the SDK compiler flags from the bitbake flags.

Maybe coming back to the original point, what would the recommended way be for developers in an SDK to create debug builds of their software? Should they attempt to filter out FORTIFY_SOURCE from the compiler flags on their own?

Could it make sense to leave things like the stack-protector flags in CC_ARCH but move just FORTIFY_SOURCE to CFLAGS as FORTIFY_SOURCE does not do anything without optimisations (which should not be part of CC/CXX)?

Thanks for any advice!

Kind regards,
Michael Ho

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