From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Bill Wendling" <morbo@google.com>, "Kees Cook" <kees@kernel.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Mark Brown" <broonie@kernel.org>,
"Marco Elver" <elver@google.com>,
alan.maguire@oracle.com, namjain@linux.microsoft.com,
"Peter Zijlstra" <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [PATCH] compiler_types: Allow opting out of __counted_by and __counted_by_ptr
Date: Mon, 05 Oct 2026 12:53:36 +0200 [thread overview]
Message-ID: <ea6e022d-e04b-42e7-b526-ac96559b3633@app.fastmail.com> (raw)
In-Reply-To: <20261005102518.2400984-1-morbo@google.com>
Hi Bill,
On Mon, 5 Oct 2026, at 12:25, 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.
>
> Overriding the macros from a Makefile doesn't work:
> 'compiler_types.h' is pulled in with '-include', which is processed
> after all -D/-U options, so it re-establishes the definitions. Follow
> the '__NO_FORTIFY' precedent instead: let a build define
> '__NO_COUNTED_BY' or '__NO_COUNTED_BY_PTR' to turn the corresponding
> annotation into a no-op. The two are kept separate but parallel so they
> can be folded together once all supported compilers handle
> '__counted_by' on pointers.
>
I'd prefer a single macro here - if there is ever a case where we need to
turn off one but not the other, we can revisit.
Otherwise, this looks good to me - thanks.
next prev parent reply other threads:[~2026-10-05 10:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 10:25 [PATCH] compiler_types: Allow opting out of __counted_by and __counted_by_ptr Bill Wendling
2026-10-05 10:44 ` Justin Stitt
2026-10-05 10:53 ` Ard Biesheuvel [this message]
2026-10-05 15:52 ` Bill Wendling
2026-10-05 19:19 ` Bill Wendling
2026-10-05 19:20 ` [PATCH v3] " Bill Wendling
2026-10-05 21:25 ` Ard Biesheuvel
2026-10-06 7:30 ` Justin Stitt
2026-10-06 8:07 ` Ard Biesheuvel
2026-10-06 9:23 ` Bill Wendling
2026-10-06 9:43 ` [PATCH v4] " Bill Wendling
2026-10-06 10:08 ` Ard Biesheuvel
2026-10-06 13:46 ` Bill Wendling
2026-10-06 14:12 ` Kees Cook
2026-10-07 9:09 ` Nathan Chancellor
2026-10-07 9:32 ` Bill Wendling
2026-10-07 9:36 ` Nathan Chancellor
2026-10-08 14:50 ` Ard Biesheuvel
2026-10-08 16:17 ` Nathan Chancellor
2026-10-08 16:40 ` Ard Biesheuvel
2026-10-08 20:29 ` Bill Wendling
2026-10-06 13:45 ` [PATCH v5] " Bill Wendling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ea6e022d-e04b-42e7-b526-ac96559b3633@app.fastmail.com \
--to=ardb@kernel.org \
--cc=alan.maguire@oracle.com \
--cc=broonie@kernel.org \
--cc=elver@google.com \
--cc=gustavoars@kernel.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=namjain@linux.microsoft.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.