Re: [PATCH 0/3] Add support for qcrypto on shikra

[Eric Biggers <ebiggers@kernel.org>]

On Mon, May 25, 2026 at 01:07:49PM +0300, Dmitry Baryshkov wrote:
> Are other harware crypto drivers faster or slower than the CPU
> implementation? What about the CAAM (sorry, it's just the driver that I
> worked with few years ago). Or Xilinx? My guess would be that for the
> most of the modern ARM64 hardware the NEON implementation is faster than
> the "hw IP" one.

Yes, QCE is hardly unique here.  It's just the one we're discussing now.

> My assumtion has always been that we support crypto IP
> for the sake of security (i.e. making sure that the key can't be found
> in the cleartext in memory dumps or that it's impossible to tamper with
> the hash values before singing/verification). From this point of view,
> using priorities is expected and logical: most of the users will need a
> quickest implementation. Some users will need to use protected keys or
> other hw-only features.
> 
> Note, I'm not commenting on the driver being buggy. If the issues are
> not fixed in a timely manner, it should be marked with 'depends on
> BROKEN' and further removed if the issues contine to be non-fixed.

Only a few drivers support protected keys ("paes", "phmac"); QCE is
*not* one of them.  There are also no explicit users of protected keys
in the kernel, so even if supported by the driver, it's almost never
used in practice in Linux.  The only way this feature could potentially
be used in Linux is if one of these drivers is present *and* userspace
explicitly chooses to use it with one of the few kernel features that
might implicitly support it, e.g. dm-crypt.  AFAIK that's extremely
rare, and at least in Linux it's really just a checkbox feature.

(HW-wrapped inline crypto keys do get used, but those don't use the
crypto API or these drivers at all.)

As for making it "impossible to tamper with the hash values before
signing/verification", these drivers don't provide anything there.

- Eric