[RFC PATCH 1/8] crypto: shash - add support for finup2x

[Herbert Xu]

On Fri, Apr 19, 2024 at 09:30:07AM -0700, Eric Biggers wrote:
>
> If you mean the fallback to scalar instructions when !crypto_simd_usable(), by
> default dm-verity and fs-verity do all hashing in process context, in which case
> the scalar fallback will never be used.  dm-verity does support the
> 'try_verify_in_tasklet' option which makes hashing sometimes happen in softirq
> context, and x86 Linux has an edge case where if a softirq comes in while the
> kernel is in the middle of using SIMD instructions, SIMD instructions can't be
> used during that softirq.  So in theory the !crypto_simd_usable() case could be
> reached then.  Either way, I have the fallback implemented in the x86 and arm64
> SHA-256 glue code for consistency with the rest of the crypto_shash API anyway.

OK that's good to hear.  So if they enable try_verify_in_tasklet
then they will only have themselves to blame :)

> If you mean falling back to two crypto_shash_finup() when the algorithm doesn't
> support crypto_shash_finup2x(), my patches to dm-verity and fs-verity do that.
> Modern x86_64 and arm64 systems will use crypto_shash_finup2x(), but dm-verity
> and fs-verity need to work on all architectures and on older CPUs too.  The
> alternative would be to put the fallback to two crypto_shash_finup() directly in
> crypto_shash_finup2x() and have the users call crypto_shash_finup2x()
> unconditionally (similar to how crypto_shash_digest() can be called even if the
> underlying shash_alg doesn't implement ->digest()).  That would make for
> slightly simpler code, though it feels a bit awkward to queue up multiple blocks
> for multibuffer hashing when multibuffer hashing won't actually be used.  Let me
> know if you have a preference about this.

No I don't think it's necessary for the time being.

Thanks,
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt