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

Maxime MERE
2025-06-25T18:30:01Z

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