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

Eric Biggers
2025-06-26T02:37:14Z

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.