Re: [f2fs-dev] [PATCH] fscrypt: don't use hardware offload Crypto API drivers
Hi, On 6/25/25 08:32, Eric Biggers wrote: That was the synchronous throughput. However, submitting multiple requests asynchronously (which again, fscrypt doesn't actually do) barely helps. Apparently the STM32 crypto engine has only one hardware queue. I already strongly suspected that these non-inline crypto engines aren't worth using. But I didn't realize they are quite this bad. Even with AES on a Cortex-A7 CPU that lacks AES instructions, the CPU is much faster! From a performance perspective, using hardware crypto offloads the CPU, which is important in real-world applications where the CPU must handle multiple tasks. Our processors are often single-core and not the highest performing, so hardware acceleration is valuable. I can show you performance test realized with openSSL (3.2.4) who shows, less CPU usage and better performance for large block of data when our driver is used (via afalg): command used: ```openssl speed -evp aes-256-cbc -engine afalg -elapsed``` ++--+-+ | Block Size (bytes) | AFALG (MB/s) | SW BASED (MB/s) | ++--+-+ | 16 | 0.09 | 9.44| | 64 | 0.34 | 11.43 | | 256| 1.31 | 12.08 | | 1024 | 4.96 | 12.27 | | 8192 | 18.18| 12.33 | | 16384 | 22.48| 12.33 | ++--+-+ to test CPU usage I've used a monocore stm32mp157f. here with afalg, we have an average CPU usage of ~75%, with the sw based approach CPU is used at ~100% Maxime ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH] fscrypt: don't use hardware offload Crypto API drivers
Hello, On 6/11/25 22:58, Eric Biggers wrote: To protect users from these buggy and seemingly unhelpful drivers that I have no way of testing, let's make fscrypt not use them. Unfortunately there is no direct support for doing so in the Crypto API, but we can achieve something very close to it by disallowing algorithms that have ASYNC, ALLOCATES_MEMORY, or KERN_DRIVER_ONLY set. I agree that software drivers are more efficient and less prone to bugs than hardware drivers. However, I would like to highlight the fact that certain ST products (the STM32MP2x series) have features that allow the loading of a secret key via an internal bus from a Secure OS to the CRYP peripheral (usable by the kernel). This enables cryptographic operations to be delegated to the non-secure side (the kernel) without exposing the key. If fscrypt no longer supports hardware drivers, then this type of functionality could not be used, which I find unfortunate because it is something that might interest users. cheers, Maxime ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [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 ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
