On Wed, Jun 25, 2025 at 06:29:17PM +0200, Maxime MERE wrote: > > > 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.
Can you please stop hijacking this thread with what is basically an irrelevant marketing blurb? The STM32 driver actually just stores the keys in memory. See stm32_cryp_ctx::key in drivers/crypto/stm32/stm32-cryp.c, and struct stm32_hash_ctx::key in drivers/crypto/stm32/stm32-hash.c. So even if the STM32 crypto engine technically supports hardware keys, the potential benefits of that are not actually being realized in Linux. And for applications like fscrypt that derive a large number of keys, it isn't actually possible to use hardware keys even if the driver supported it, without key wrapping and proper integration with the key hierarchy. (FWIW, the hardware-wrapped inline encryption keys feature does do that, but that is very different from what we're talking about here.) Also, the STM32 driver does not actually fully support any of fscrypt's file contents encryption modes. It does support AES-256-ECB and AES-128-CBC, so it can be used for AES-256-XTS and AES-128-CBC-ESSIV when the CPU handles the XTS masking or IV encryption respectively. But to do that, the CPU needs access to part of the secret keys. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
