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

[Maxime MERE]

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