linux-kernel - Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <c1671c5e-d824-4131-861e-470d09371e05@foss.st.com>
Date: Wed, 25 Jun 2025 18:29:17 +0200
From: Maxime MERE <maxime.mere@...s.st.com>
To: Eric Biggers <ebiggers@...nel.org>
CC: <linux-fscrypt@...r.kernel.org>, <linux-crypto@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-mtd@...ts.infradead.org>,
        <linux-ext4@...r.kernel.org>, <linux-f2fs-devel@...ts.sourceforge.net>,
        <ceph-devel@...r.kernel.org>
Subject: Re: [PATCH] fscrypt: don't use hardware offload Crypto API drivers

On 6/13/25 16:42, Eric Biggers wrote:
> Honestly, the responses to this thread so far have made it even more clear that
> this patch is the right decision.

The chaining system I previously presented is just an example intended 
to demonstrate the value of hardware drivers in the context of ST platforms.

The key point is that our hardware IP allows us to securely embed 
encryption keys directly in hardware, making sure they are never visible 
or accessible from Linux, which runs in a non-secure environment. Our 
software architectures rely on a Secure OS running in parallel with 
Linux, similar to what is done on Android. This Secure OS is responsible 
for sensitive cryptographic operations.

This Secure OS can manages the keys with a dedicated hardware peripheral 
(SAES). The Linux side never sees the keys directly. Instead, the Secure 
OS prepares the keys and shares them securely with the cryptographic 
engine (CRYP) through a dedicated hardware bus.

This architecture improves security boundary: keys isolated from the 
non-secure Linux environment. But decryption can be processed by the 
linux kernel.

In addition, ST’s hardware crypto peripherals come with built-in 
protections against side-channel attacks and have been certified with 
SESIP and PSA level 3 security assurance, providing a level of security 
difficult to achieve with software alone.

Regarding robustness and maintenance, ST ensures regular updates of its 
drivers and can fix any reported bugs. We have conducted internal tests 
with dm-crypt that demonstrate the proper functioning of these drivers 
for this type of application.

Maxime