On Wed, Apr 24, 2024 at 09:13:51PM -0700, Eric Biggers wrote: > > +.. [#dmveritydigests] These hash algorithms are based on values accepted by dm-verity, > > + specifically ``crypto_alloc_ahash`` in ``verity_ctr``; ``veritysetup`` > > + does support more algorithms than the list above. IPE does not impose > > + any restrictions on the digest algorithm itself; thus, this list > > + may be out of date. > > References to specific functions and locations in the code tend to get out of > date. I think you mean something like: any hash algorithm that's supported by > the Linux crypto API is supported. > Also, this scheme looks buggy because it's directly reusing the crypto API's algorithm name string as the digest name. The crypto API lets you specify the name of an algorithm, like "sha256", but it also lets you specify the name of a particular *implementation* of an algorithm, like "sha256-ni" for the SHA-NI accelerated implementation of sha256. It looks like dm-verity just passes through the name directly to the crypto API, and as a result it accepts names like sha256-ni. Since you're directly passing the same name into the security_bdev_setintegrity() LSM hook, that would result in IPE being told that the hash is "sha256-ni". That doesn't make sense. I think you want to be passing in crypto_ahash_alg_name(v->tfm), not v->alg_name. - Eric
