Re: [PATCH v2] drivers/crypto: Mark QCE as BROKEN

[Eric Biggers]

On Wed, Jul 22, 2026 at 01:33:51AM -0700, Bartosz Golaszewski wrote:
> We can offload crypto operations to the QCE saving CPU cycles

Here are benchmark results for SHA-256 on the SM8650 HDK, hashing 50000
4096-byte messages (matching dm-verity's and fsverity's workloads), with
all your pending patches applied:

sha256-lib (i.e. ARMv8 CE):

    Wall-clock elapsed time: 0.10s
    CPU time used: 0.10s
    CPU time spent in hardirq context: 0.00s
    CPU time spent in softirq context: 0.00s

sha256-qce:

    Wall-clock elapsed time: 10.76s
    CPU time used: 5.14s
    CPU time spent in hardirq context: 0.77s
    CPU time spent in softirq context: 2.31s

So sha256-qce is over 100 times slower and uses over 50 times more CPU
than ARMv8 CE, over half of that in hardirq or softirq context.

This was even worse than what I got last time I tried this!  So I tried
rolling back your BAM locking patches:

    Wall-clock elapsed time: 4.85s
    CPU time used: 2.78s
    CPU time spent in hardirq context: 0.55s
    CPU time spent in softirq context: 0.94s

That's more in line with what I measured last time I tried this, but
still atrocious.  It's still far more CPU time used than just doing the
hashing on the CPU, and much of it spent in hardirq and softirq
contexts.  The BAM locking just makes it even worse.

With that, plus the security claims not panning out either when
considering the actual code and usage in Linux, and also all the bugs
(both historical and current unfixed ones), I don't think there's any
credibility left.  This legacy driver should just be deleted.

To be clear: completely separate from QCE, Qualcomm SoCs have good
support for crypto acceleration in ICE and the ARMv8 CE.  That's great!
And that is, of course, what is *actually* being used in Linux.  That's
what we'll support.  Let's stop wasting time on a dead-end approach.

I understand there may be a desire to keep this driver around so that
support for restricted media content can be added to it.  However, that
would be new functionality that has nothing to do with what the driver
currently does and doesn't use the kernel's crypto API.  There's no need
to keep the driver around for this.  Just put together a clean proposal
to add a new version of the driver with just the needed functionality
(note that drivers/crypto/ probably won't be the right place for it).

- Eric