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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
