Re: [PATCH v4] compiler_types: Allow opting out of __counted_by and __counted_by_ptr

[Kees Cook <kees@kernel.org>]

On Tue, Oct 06, 2026 at 09:43:58AM +0000, Bill Wendling wrote:
> Code that runs outside the kernel proper, such as the EFI stub, gets
> nothing out of the counted_by annotations: the bounds checks they feed
> (FORTIFY_SOURCE, UBSAN_BOUNDS) are already disabled there.
> 
> The annotations can also break the build. A __counted_by_ptr() that
> names a member declared after the pointer needs Clang's
> '-fexperimental-late-parse-attributes', which the top-level Makefile
> adds to 'KBUILD_CFLAGS'. The x86 EFI stub builds its own cflags and does
> not get that flag, so it fails as soon as such a struct is pulled in
> through a common header.

We have a distinction between parsing and output (instrumentation,
linkage, etc). FORTIFY_SOURCE and UBSAN_BOUNDS (and lots of other
things) control output (e.g. fortify alternative linkages, ubsan
instrumentation). We don't normally have parsing issues, as that kind
of thing is usually controlled by compiler flag options (like here). For
example, if a transparent struct ever leaked into a header that libstub
includes, we would explode as well, due to x86's resulting lack of
-fms-extensions.

So, I this should _not_ be managed with a NO_* flag, as that has been
traditionally about suppressing output. I don't think we want to mix
that idiom with parsing issues.

And other architectures solve this problem by not wiping KBUILD_CFLAGS in
the first place. :P So if we want to continue to accept the x86 exception
(which I would argue is the actual problem), we likely need to, instead,
construct an explicit export that is used to collect parsing control
options so that it can be re-included here. Today, I can think of
-fms-extensions besides -fexperimental-late-parse-attributes.

KBUILD_PARSE_CFLAGS += -fms-extensions
...
KBUILD_PARSE_CFLAGS += -fexperimental-late-parse-attributes
...
export KBUILD_PARSE_CFLAGS
KBUILD_CFLAGS += $(KBUILD_PARSE_CFLAGS)
...

We already do something like this for CLANG_FLAGS, which, given
-fexperimental-late-parse-attributes being Clang-specific, perhaps we
ignore my -fms-extensions future-proofing, and just add it there, but
it doesn't look like that is how scripts/Makefile.clang was intended to
be used.

But, again, I think the problem is x86's wipe of the flags. In fact, I
see an explicit problem with that today, which is the loss of
-fauto-trivial-var-init, which all the other arch's stub gain (it's an
output flag, but it happens to neither change linkage nor create hooked
instrumentation). So x86 efi stub lacks stack var zeroing but all the
other archs have it.

Can we just fix x86 correctly to use filter-out, etc, there?

-Kees

-- 
Kees Cook