Re: [PATCH v4 06/46] fscrypt: expose fscrypt_nokey_name

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Dec 01, 2023 at 05:11:03PM -0500, Josef Bacik wrote:
> -/*
> - * Decoded size of max-size no-key name, i.e. a name that was abbreviated using
> + * Decoded size of max-size nokey name, i.e. a name that was abbreviated using
>   * the strong hash and thus includes the 'sha256' field.  This isn't simply
>   * sizeof(struct fscrypt_nokey_name), as the padding at the end isn't included.
>   */

The above change seems accidental?  Note that while the C identifiers use
"nokey", in text I've been writing it as "no-key".

> diff --git a/include/linux/fscrypt.h b/include/linux/fscrypt.h
> index 5f5efb472fc9..f57601b40e18 100644
> --- a/include/linux/fscrypt.h
> +++ b/include/linux/fscrypt.h
> @@ -17,6 +17,7 @@
>  #include <linux/mm.h>
>  #include <linux/slab.h>
>  #include <linux/blk-crypto.h>
> +#include <crypto/sha2.h>
>  #include <uapi/linux/fscrypt.h>
>  
>  /*
> @@ -56,6 +57,42 @@ struct fscrypt_name {
>  #define fname_name(p)		((p)->disk_name.name)
>  #define fname_len(p)		((p)->disk_name.len)
>  
[...]
> +struct fscrypt_nokey_name {
> +	u32 dirhash[2];
> +	u8 bytes[149];
> +	u8 sha256[SHA256_DIGEST_SIZE];
> +}; /* 189 bytes => 252 bytes base64url-encoded, which is <= NAME_MAX (255) */

I'd be tempted to just change SHA256_DIGEST_SIZE to 32, which would avoid
needing to include crypto/sha2.h.  The size is effectively hardcoded anyway, via
the 'u8 bytes[149];' field.  And it's not like SHA-256 will stop being 256 bits.

- Eric