Re: [PATCH 0/3] Add support for qcrypto on shikra

From: Eric Biggers

Date: Thu May 28 2026 - 13:58:19 EST


On Thu, May 28, 2026 at 11:13:47AM -0400, Bartosz Golaszewski wrote:
> On Thu, 28 May 2026 15:50:10 +0200, Dmitry Baryshkov
> <dmitry.baryshkov@xxxxxxxxxxxxxxxx> said:
> > On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote:
> >> On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh
> >> <kuldeep.singh@xxxxxxxxxxxxxxxx> said:
> >> >>> +Bartosz, Gaurav, Neeraj
> >>
> >> I know about the self-tests etc., I will address them next.
> >
> > My 2c, the self-tests would be more important, as they are fixes. Doing
> > the crypto in a wrong way is a bad idea...
> >
>
> Then let that be "in parallel". :)

The race conditions between Linux and other environments (modem, TEE,
etc) are of course about correctness as well, even though the self-tests
don't expose race condition bugs. The self-tests have always just done
a few serialized tests. That's sufficient for CPU-based code, but not
for offload drivers, which need to be stress-tested to find the
concurrency bugs that occur during actual use.

Is there a plan to improve the tests to do stress testing as well?

It's kind of odd that they don't do that yet. But it makes sense: the
CPU-based code doesn't need it, while the offload driver authors have
never cared enough about correctness and test coverage to add it.

I still don't really see a path forward here, given the track record and
poor performance numbers. This approach just doesn't work.

- Eric