linux-kernel - Re: [PATCH libcrypto v2 2/3] compiler: introduce at_least parameter decoration pseudo keyword

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXG0adfCkuM4f92csxF0bxxBo6sNe_iJ_szKNEcEfgFwqg@mail.gmail.com>
Date: Sat, 22 Nov 2025 12:53:58 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, torvalds@...ux-foundation.org, ebiggers@...nel.org, 
	kees@...nel.org, linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH libcrypto v2 2/3] compiler: introduce at_least parameter
 decoration pseudo keyword

On Sat, 22 Nov 2025 at 04:08, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Sat, Nov 22, 2025 at 03:46:38AM +0100, Jason A. Donenfeld wrote:
> >
> > Saw your reply to v1 and was thinking about that. Will do. Thanks for
> > pointing this out.
>
> It seems that we need to bring the brackets back, because sparse
> won't take this either:
>
> int foo(int n, int a[n])
> {
>         return a[0]++;
> }
>
> But this seems to work:
>
> #ifdef __CHECKER__
> #define at_least(x)
> #else
> #define at_least(x) static x
> #endif
>
> int foo(int n, int a[at_least(n)])
> {
>         return a[0]++;
> }
>

This is a different idiom: n is a function argument, not a compile
time constant.

Clang and GCC both appear to permit it, but only GCC [11 or newer]
emits a diagnostic when 'n' exceeds the size of a[]. There is also
work ongoing to support the counted_by variable attribute for formal
function parameters in both compilers.

So for the moment, I think we should limit this to compile time
constants only, in which case sparse is happy too, right?