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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ikktgx57.fsf@kamlesh.mail-host-address-is-not-set>
Date: Wed, 18 Jun 2025 16:00:12 +0530
From: Kamlesh Gurudasani <kamlesh@...com>
To: Eric Biggers <ebiggers@...nel.org>, T Pratham <t-pratham@...com>
CC: Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller"
	<davem@...emloft.net>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, <linux-crypto@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Vignesh Raghavendra <vigneshr@...com>,
        Praneeth Bajjuri <praneeth@...com>,
        Manorit Chawdhry <m-chawdhry@...com>
Subject: Re: [PATCH v5 0/2] Add support for Texas Instruments DTHE V2 crypto
 accelerator

Eric Biggers <ebiggers@...nel.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@...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

> Note that the manual you linked to above explicitly states that the CPU supports
> the ARMv8 Cryptography Extensions.  That definitively makes any off-CPU offload
> obsolete.  But even without that, these sorts of off-CPU offloads have always
> been highly questionable.
>
> I think it's implausible that this patchset could actually be beneficial.
>
> In fact, it might actually be really harmful.  You set your algorithms to
> priority 30000, which makes them be prioritized over ARMv8 CE.  I've seen
> exactly that bug with other "accelerators", which actually regressed performance
> by over 50x compared to simply staying on the CPU.
>
> - Eric