Re: [PATCH v2 06/13] lib/crypto: aes: Add GCM support

On 16/07/2026 00.11, Eric Biggers wrote:
> Add support for AES-GCM to the crypto library.
> 
> This will be used to provide streamlined implementations of the
> "gcm(aes)" and "rfc4106(gcm(aes))" crypto_aead algorithms.  Most users
> of these will also be able to switch to the library, which as usual will
> be faster and simpler, e.g.:
> 
>    - drivers/net/macsec.c
>    - fs/smb/client/
>    - fs/smb/server/
>    - net/ceph/messenger_v2.c
>    - net/mac80211/ (for both GMAC and GCMP)
>    - net/tipc/crypto.c
>    - security/keys/trusted-keys/trusted_dcp.c
> 
> (I've already written proof-of-concept patches for all the above, and
> they helped inform the API design.)
> 
> As usual, the architecture-optimized AES-GCM code will be migrated into
> the library as well (using the hooks provided in this commit as well as
> the GHASH ones), eliminating lots of repetitive boilerplate code.
> 
> Incremental en/decryption is supported.  Incremental operation is a bit
> controversial in AEAD APIs because users have to be careful not to
> consume any decrypted data that hasn't been authenticated yet.  But I do
> think it's the right choice here.  It's not fundamentally different from
> the existing incremental MAC APIs, and it's the only approach that's
> general enough to work well for all users in the kernel:
> 
>    - An array of virtually-addressed buffers (like that used by
>      BoringSSL's EVP_AEAD_CTX_sealv() and EVP_AEAD_CTX_openv()) doesn't
>      work in the kernel in general, since in some cases the data for a
>      single AES-GCM message is contained in a large number of highmem
>      pages that each need to be mapped into memory individually.  That
>      can be done efficiently only by using CPU-local mappings, but there
>      is a limited number of those.
> 
>      Ceph messenger v2 is a great example, as it can send or receive up
>      to 32 MiB in a single AES-GCM message.  And it needs the
>      en/decrypted data to go into a (potentially large) number of bvecs
>      provided by a custom iterator, as well as into four
>      virtually-addressed buffers, two of which can be large buffers in
>      the vmalloc region.
> 
>      Even just allocating an array big enough to store all the pointers
>      can be problematic in the kernel.  There are cases in which
>      decryption runs in GFP_NOIO context or even in softirq context,
>      where memory allocations are not as reliable as they normally are.
> 
>    - Meanwhile, 'struct scatterlist' (the choice of crypto_aead) has
>      turned out to be really inconvenient for anyone who *does* just have
>      virtually-addressed buffers.  This is especially true if they can be
>      in the vmalloc region, including the stack, as in that case the
>      conversion to a scatterlist has to be done page-by-page.
> 
>      And even for users who have all of their data in bare 'struct page',
>      none of them actually use 'struct scatterlist' as their native data
>      structure anyway.  They actually use skbs, bvecs, or other formats.
> 
>    - iov_iter is attractive, but ultimately not general enough either
>      (considering the Ceph case for example), but also too general in
>      some ways (like having support for userspace addresses).  Additional
>      iter types like ITER_SKB would help a bit, but bloating iov_iter
>      with more types would reduce performance elsewhere in the kernel.
> 
> Initial test coverage is provided by the crypto_aead support added in a
> later commit.  I'm planning a KUnit test suite as well.
Sorry for asking ignorant questions, but which later commit is this? I 
couldn't spot it :-/

Anyway, the previous AES-GCM code in lib/crypto/aesgcm.c featured some 
self-tests in libaesgcm_init() ... would it maybe make sense to add those 
here, too?

  Thomas