All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-crypto@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Eric Biggers <ebiggers@kernel.org>,
	arnd@arndb.de
Subject: Re: [RFC PATCH] libcrypto/chachapoly: Use strict typing for fixed size array arguments
Date: Fri, 14 Nov 2025 21:23:34 +0100	[thread overview]
Message-ID: <aRePu_IMV5G76kHK@zx2c4.com> (raw)
In-Reply-To: <20251114180706.318152-2-ardb+git@google.com>

On Fri, Nov 14, 2025 at 07:07:07PM +0100, Ard Biesheuvel wrote:
> void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
>                                const u8 *ad, const size_t ad_len,
>                                const u8 (*nonce)[XCHACHA20POLY1305_NONCE_SIZE],
>                                const u8 (*key)[CHACHA20POLY1305_KEY_SIZE])
> 
> However, this variant is checked more strictly by the compiler, and only
> arrays of the correct size are accepted as plain arguments (using the &
> operator), and so inadvertent mixing up of arguments or passing buffers
> of an incorrect size will trigger an error at build time.

Interesting idea! And codegen is the same, you say?

There's another variant of this that doesn't change callsites and keeps
the single pointer, which more accurate reflects what the function does:

void xchacha20poly1305_encrypt(u8 *dst, const u8 *src, const size_t src_len,
                               const u8 *ad, const size_t ad_len,
                               const u8 nonce[static XCHACHA20POLY1305_NONCE_SIZE],
                               const u8 key[static CHACHA20POLY1305_KEY_SIZE])

An obscure use of the `static` keyword, but this is what it's used for -
telling the compiler what size you expect the object to be. Last time I
investigated this, only clang respected it, but now it looks like gcc
does too:

    zx2c4@thinkpad /tmp $ cat a.c
    
    void blah(unsigned char herp[static 7]);
    
    static void schma(void)
    {
        unsigned char good[] = { 1, 2, 3, 4, 5, 6, 7 };
        unsigned char bad[] = { 1, 2, 3, 4, 5, 6 };
        blah(good);
        blah(bad);
    }
    zx2c4@thinkpad /tmp $ gcc -c a.c
    a.c: In function ‘schma’:
    a.c:9:9: warning: ‘blah’ accessing 7 bytes in a region of size 6 [-Wstringop-overflow=]
        9 |         blah(bad);
          |         ^~~~~~~~~
    a.c:9:9: note: referencing argument 1 of type ‘unsigned char[7]’
    a.c:2:6: note: in a call to function ‘blah’
        2 | void blah(unsigned char herp[static 7]);
          |      ^~~~
    zx2c4@thinkpad /tmp $ clang -c a.c
    a.c:9:2: warning: array argument is too small; contains 6 elements, callee requires at least 7
          [-Warray-bounds]
        9 |         blah(bad);
          |         ^    ~~~
    a.c:2:25: note: callee declares array parameter as static here
        2 | void blah(unsigned char herp[static 7]);
          |                         ^   ~~~~~~~~~~
    1 warning generated.


This doesn't account for buffers that are oversize -- the less dangerous
case -- but maybe that's fine, to keep "normal" semantics of function
calls and still get some checking? And adding `static` a bunch of places
is easy. It could apply much wider than just chapoly.

This all makes me wish we had NT's SAL notations though...

Jason

  reply	other threads:[~2025-11-14 20:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14 18:07 [RFC PATCH] libcrypto/chachapoly: Use strict typing for fixed size array arguments Ard Biesheuvel
2025-11-14 20:23 ` Jason A. Donenfeld [this message]
2025-11-14 20:33   ` Ard Biesheuvel
2025-11-15  2:14     ` Eric Biggers
2025-11-15 17:11       ` Linus Torvalds
2025-11-15 17:32         ` Linus Torvalds
2025-11-15 17:39         ` Jason A. Donenfeld
2025-12-02  1:12           ` Alejandro Colomar
2025-12-02  1:57             ` Eric Biggers
2025-12-02 10:14               ` Alejandro Colomar
2025-12-02 13:42                 ` Alejandro Colomar
2025-12-02 16:49                   ` Eric Biggers
2025-12-02 21:27                     ` Alejandro Colomar
2025-12-03 17:24             ` Daniel Thompson
2025-12-03 18:01               ` Alejandro Colomar
2025-12-05 13:59                 ` Daniel Thompson
2025-12-13 20:04                   ` Alejandro Colomar
2025-11-16 13:57 ` kernel test robot

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=aRePu_IMV5G76kHK@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.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.