On Wed, Jun 25, 2025 at 06:29:17PM +0200, Maxime MERE wrote: > 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.
In addition to the bug I mentioned earlier where the STM32 crypto driver produced incorrect ciphertext (https://github.com/google/fscryptctl/issues/32), the following fix shows that the STM32 crypto driver computed incorrect hash values for years (2017 through 2023): https://git.kernel.org/linus/e6af5c0c4d32a27e While these bugs may be fixed now, they show a serious lack of testing. They also show that these sorts of drivers are really hard to get right. I absolutely do not want fscrypt using anything like this. I want the crypto to be done correctly. (And also efficiently, which clearly these offloads don't actually do either.) BTW, it seems all the hardware offload crypto drivers have quality issues like this. I gave other examples in the thread, for example the Intel QAT driver causing data corruption. So my intent isn't to single out the STM32 driver per se. (And of course this patch applies to all drivers.) I'm just responding to STM32 because of the people pushing it in this thread for some reason. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
