Re: [PATCH v4 13/13] lib/crypto: Add documentation about zeroization of key and context data

[Thomas Huth <thuth@redhat.com>]

On 30/09/2026 22.14, Eric Biggers wrote:
> On Wed, Sep 16, 2026 at 11:50:15AM +0200, Thomas Huth wrote:
>> +What to zeroize
>> +---------------
>> +
>> +The following types of structures hold sensitive material and should be
>> +zeroized after use:
>> +
>> +- **Key structures** (e.g. ``struct aes_key``, ``struct hmac_sha256_key``):
>> +  contain expanded round keys or prepared key material.
>> +
>> +- **HMAC/MAC context structures** (e.g. ``struct hmac_sha256_ctx``,
>> +  ``struct aes_cmac_ctx``): contain inner and outer hash states derived from
>> +  the key.
>> +
>> +- **Hash context structures** (e.g. ``struct sha256_ctx``): may contain
>> +  sensitive data being hashed.
>> +
>> +Not all of these require explicit cleanup by callers.  Many ``..._final()``
>> +functions already zeroize their context internally (see `Automatic vs. manual
>> +zeroization`_ below).
> 
> This should mention that the raw key that the key struct was prepared
> from needs to be zeroized as well.  Every in-kernel user of a keyed
> algorithm has to deal with this problem, as to "prepare" a key, you need
> to have the key already in the first place (whether it's passed in from
> userspace, or derived from some other key, or something else).
> 
> Zeroizing a 'struct aes_key' for example is kind of useless if the
> actual raw AES key is still in memory somewhere.
> 
> Any interest in sending a follow-up patch that clarifies this?  It
> really should clarify that users of cryptography in the kernel should
> apply zeroization to the full flow of their keys through the system
> including system calls, key derivation, key preparation, etc.
Agreed, adding some wording about raw keys makes sense. However, I'll be 
very short in time during the next one or two weeks, so if you would like to 
do it, please go ahead and send a patch. Otherwise I'll look into this in a 
week or two when I've got some more spare time again.

  Thanks,
   Thomas