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

From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org, fsverity@lists.linux.dev,
	dm-devel@lists.linux.dev, x86@kernel.org,
	linux-arm-kernel@lists.infradead.org, ardb@kernel.org,
	samitolvanen@google.com, bvanassche@acm.org
Subject: Re: [RFC PATCH 1/8] crypto: shash - add support for finup2x
Date: Fri, 26 Apr 2024 16:56:50 +0800	[thread overview]
Message-ID: <ZitsUtjm7/tuWwqM@gondor.apana.org.au> (raw)
In-Reply-To: <20240419163007.GA1131@sol.localdomain>

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@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt