Ubuntu -fcf-protection=full breaking code

[Matthias Klose]

On 2/15/21 3:17 AM, Alex Murray wrote:
> Hi Michael,
> 
> For Ubuntu we try and take an approach where we want as much code that
> is compiled for and *on* Ubuntu to try and take advantage of the various
> toolchain hardening options that are available.  This gives end-users
> the most protection with the least amount of work.

Alex, this doesn't match my memory.  Turning on the hardening flags always was a
hack to build packages with hardening flags that ignored flags in their build
system, which are set by the packaging code.

> In some cases however, this can lead to issues as noted in the github
> issue you linked to - not all compiler options will be suitable for all
> codebases etc. However, there are a huge number of codebases which are
> suitable for this kind of feature and automatically benefit from
> this. Also as Ubuntu is used by a huge number of software developers and
> is a platform of choice in CI/CD systems, this then allows many
> codebases to automatically benefit from these default hardening
> features. To make control-flow protection usable in practice, not only
> does the binary need to be compiled with this enabled, but also all
> shared libraries etc. If a user wants to compile a newer version of a
> library, they can then simply do the usual, configure && make && make
> install, and it will get compiled with these CFLAGS as well (whereas
> were this done solely via dpkg-buildflags or similar, only
> binaries/libraries shipped via debs would likely be compiled with this
> feature which would then make it a bit pointless if some libraries have
> it on but others do not).
> 
> So as with all things, there is a balance that needs to be struck
> between the two - the current solution allows this default to be turned
> off via CFLAGS as mentioned at
> https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection if
> needed - but also ensures that as many different packages or bespoke
> codebases will be compiled with this option on (and as such likely then
> ensure it can be used in end-deployments as with any luck all dependent
> libraries get compiled with it on as well).

The current "balance" is to force things into GCC first, and then tending to
ignore or delay any follow-up work.  -fcf-protection and
-fstack-clash-protection don't show up in build logs for package builds, so at
least for package builds, package maintainers don't easily see which hardening
flags are in use.

Software built by other compilers doesn't take "advantage of the various
toolchain hardening options", so I think your claim made in the first paragraph
is at least misleading.  Non-package builds don't see any of these hardening
options, as well as packages ignoring options set in the build environment.
Even packages respecting their build environment don't see -fcf-protection and
-fstack-clash-protection at all.  Users are also happy using these compilers to
work around the Ubuntu GCC settings with the least amount of work.

Matthias

> 
> Thanks,
> Alex
> 
> On Tue, 2021-02-09 at 05:40:40 +1030, michael Bostwick wrote:
> 
>> Any idea why
>> Overriding the default flags to include -fcf-protection=full breaks ipxe,
>> and other tooling not coded to work around it as can be seen on github:
>> https://github.com/ipxe/ipxe/commit/e8393c3728bf7073d033410373ef6781549c7c3e#commitcomment-46894324
>>
>>
>> There is an easier and more straightforward work around (preferred CFLAGS
>> within the package build), why not use that ?
> 
>