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
