Re: [PATCH v3 0/5] fcntl fortification

["Zack Weinberg" <zack@owlfolio.org>]

On Tue, Jun 20, 2023, at 8:53 AM, Sergey Bugaev via Libc-alpha wrote:
> I'm not using Ubuntu.
> Do they just set _FORTIFY_SOURCE by default -- i.e. not only when
> building OS packages, but for all compilations? That's... unusual :|

To me it looks like they only set it when building packages:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.1 LTS
Release:	22.04
Codename:	jammy

$ which gcc
/usr/bin/gcc

$ echo '#include <string.h>' | gcc -E -dD -xc - | grep FORTIFY
#undef __USE_FORTIFY_LEVEL
#define __USE_FORTIFY_LEVEL 0
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)

$ dpkg-buildflags | grep FORTIFY
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2

> It's also concerning that check-installed-headers doesn't check this
> configuration (_FORTIFY_SOURCE with non-GNU C standard), and we're
> only finding out about this by accident. There's a comment in
> check-installed-headers.sh that says:
>
> # An exhaustive test of feature selection macros would take far too long.
> # These are probably the most commonly used three.
>
> That makes sense when running the testsuite locally since you want it
> to finish in minutes, not days, but wouldn't checking all combinations
> (or at least _a lot_ more of them) make more sense for CI?

When I wrote check-installed-headers, IIRC, the only CI we had was
Joseph's build-many-glibcs bot, which was already struggling to keep
up just with the load from its own built in list of configurations.

It may well make sense to change this now, and I agree that permutations
involving _FORTIFY_SOURCE should be a priority since fortification makes
so many changes to important headers.

zw