[PATCH 01/21] Add --enable-fortify-source option

[Adhemerval Zanella Netto]

On 22/06/23 09:50, Siddhesh Poyarekar wrote:
> On 2023-06-22 08:29, Adhemerval Zanella Netto wrote:
>>>> I'd be happy to get more feedback on whether I should enforce
>>>> disablement or not, especially from people who deal with distribution
>>>> that set it by default.
>>>
>>> My worry is that with this on Ubuntu/Gentoo, there's no way through configure to disable fortification, which, importantly, is current behaviour.  The only way to do it would then be to pass CFLAGS to override the toolchain.  It's not the worst problem to have TBH, but I'd like Ubuntu or Gentoo maintainers to explicitly opt into it instead of us forcing it on them.
>>
>> Do we really need another configure option? Any extra option requires extra
>> maintainability effort to avoid it to bit-rotten (like --disable-shared [1]),
>> this option would most likely to be always used (specially because distros
>> are enabling fortify as default), and the fortify coverage are a superset
>> of the default prototypes (meaning that programs that built and run with
>> fortify enable should also run without it).
> 
> The option is needed for the small device users, where they often don't want to build with stack protector, fortification, or really anything that would accidentally make their devices more secure (sorry ;)).

But which is the size and performance implication for glibc itself by
enabling fortify as default?

> 
> The broader plan we had in mind was to disable by default in glibc-2.38 and then enable by default in glibc-2.39.  That would also mean adding a b-m-g target with --disable-fortify to ensure that it doesn't bitrot.

This has the drawback to require even more computer power to check all
possible variants. We already have --disable-default-pie, 3 modes
for --enable-stack-protector; and now for fortify it means another
option.  Each configuration flag adds quadratic more requirement to
check if all permutation does not break, which is far from ideal.

> 
> Alternatively if we're feeling adventurous, we could just enable by default in 2.38 and be done with it.  Like you said, most distributions will enable it at first opportunity anyway and doing it by default is easier than modifying the build config to add a flag.  Let them add a flag if it's actually breaking things.  What do you think?
> 

My take is do not add any more configuration flag and if user want to enable
fortify the best option would be through CC/CFLAGS. We already have specific
Makefile rules to disable where it is not applicable (similar to stack
protector), so I think we should follow the same pattern and assume it might
be enabled, disable where it is not applicable, and fix the potential issues
(as the rest of this patch).

In fact, I think we should do something similar to PIE and stack protector.