Ubuntu -fcf-protection=full breaking code

[Alex Murray]

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.

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

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 ?