Re: [PATCH v5 0/2] Add support for Texas Instruments DTHE V2 crypto accelerator

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jun 18, 2025 at 04:00:12PM +0530, Kamlesh Gurudasani wrote:
> Eric Biggers <ebiggers@kernel.org> writes:
> 
> > On Tue, Jun 03, 2025 at 06:07:27PM +0530, T Pratham wrote:
> >> This series adds support for TI DTHE V2 crypto accelerator. DTHE V2 is a
> >> new crypto accelerator which contains multiple crypto IPs [1].
> >> This series implements support for ECB and CBC modes of AES for the AES
> >> Engine of the DTHE, using skcipher APIs of the kernel.
> >> 
> >> Tested with:
> >> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> >> CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y
> >> 
> >> and tcrypt,
> >> sudo modprobe tcrypt mode=500 sec=1
> >> 
> >> Signed-off-by: T Pratham <t-pratham@ti.com>
> >> ---
> >> [1]: Section 14.6.3 (DMA Control Registers -> DMASS_DTHE)
> >> Link: https://www.ti.com/lit/ug/sprujb4/sprujb4.pdf
> >
> > Numbers, please.  What is the specific, real use case in Linux where this
> > patchset actually improves performance?  Going off the CPU and back again just
> > to en/decrypt some data is hugely expensive.
> >
> We don't really care about the speed here. These crypto accelerators are
> from embedded system. Often less than 4 cores and this particular SOC
> have variant with only one core.
> 
> ARMv8 is clocking at 1.4ghz and DTHEv2 at 400Mhz, so no way it can give
> better performance number in term of speed. But crypto acclerators are
> designed specifically for lower power consumption as well. ARMv8 crypto
> extensions leverage SIMD registers, but dedicated crypto accelerator are
> still more efficient. Think about battery operated low cost devices. 
> 
> These embedded devices are often in the open and vicinity of attacker.
> Crypto accelerator are much more secure.[1]
> 
> Bottomline:
> 1. Crypto accelerators can deliver a higher cryptography performance.
> 2. Crypto accelerators can deliver better energy efficiency.
> 3. Cryptography hardware usually has lower timing and power side channel leakage than running
> cryptography algorithms on the processor.
> 
> IPSEC and partition encryption/decryption/authentication use cases are bulk
> operations and often have low setup cost than operation itself. 
> 
> [1] https://www.trustedfirmware.org/docs/Introduction_to_Physical_protection_for_MCU_developers_final.pdf
> 
> Cheers,
> Kamlesh

Okay, so you admit that your "accelerator" is much slower than the CPU.  So (1)
does not apply.

As for (2), it's not clear that applies here.  Sure, your AES engine *by itself*
may be more power-efficient than the AES instructions on the CPU.  However,
using the offload requires all the additional work associated with offloading
the operation from the CPU.  Since it's much slower, it will also cause the
operation to be dragged out over much a longer period of time, keeping the
system awake for longer when it could have gone into suspend earlier.

Thus, using the "accelerator" could actually increase power usage.

As for (3), a couple issues.  First, you're just making an argument from
generalities and are not claiming that it's actually true in this case.  ARMv8
CE instructions are in fact constant time.

Sure, ARMv8 CE is generally not hardened against power analysis attacks.  But
you haven't actually claimed that your crypto engine is either.

Second, these side channels, especially the ones other than timing, just aren't
part of the threat model of most users.

Meanwhile, a security issue we do have is that the hardware drivers tend not to
be tested before the kernel is released, and often are released in a broken
state where they don't even do the en/decryption correctly.  Furthermore,
unprivileged userspace programs may use AF_ALG to exploit buggy drivers.

It seems implausible that this patch is more helpful than harmful.

- Eric