Re: [PATCH] crypto: qce - Remove driver

Re: [PATCH] crypto: qce - Remove driver

[Greg Kroah-Hartman]

On Thu, Jul 23, 2026 at 10:06:45PM -0700, Eric Biggers wrote:
> This obsolete driver was already marked as BROKEN.  However, keeping
> BROKEN code around in the tree is unnecessary and causes problems.  It's
> much better to just remove it entirely.  Let's do that.
> 
> Crypto acceleration remains well-supported on Qualcomm SoCs via the
> Qualcomm Inline Crypto Engine and the ARMv8 Crypto Extensions, which are
> what Linux actually uses in practice.  The obsolete QCE driver is a
> dead-end approach.  It's extremely slow and just doesn't work well.
> 
> While there's been discussion around using QCE for restricted media
> content protection, that functionality has very little to do with the
> current crypto API driver and belongs in a separate, clean proposal
> (likely under a different subsystem/directory).
> 
> The extensive reasons for marking this driver as BROKEN were already
> documented in commit df373d39c6f0 ("crypto: qce - Mark QCE as BROKEN").
> 
> Since then, it's also been found that under realistic workloads, the
> driver is not only ~48x slower than ARMv8 CE, but due to massive driver
> overhead it actually consumes significantly *more* CPU cycles than doing
> the hashing directly on the CPU -- with much of that time spent in
> non-preemptible hardirq and softirq contexts
> (https://lore.kernel.org/linux-crypto/20260724020608.GA51735@sol/).  The
> proposed BAM locking fixes would only further degrade performance.
> 
> Additional bugs have been found as well
> (https://lore.kernel.org/linux-crypto/20260723205801.GD110634@quark/).
> Pending fixes for some bugs don't change the big picture.  Nor have
> security-related claims held up.  Of course, these issues are largely
> moot anyway when this driver's functionality isn't being used in
> practice, beyond the module loading due to it being in the kconfig.
> 
> Note that this removal does *not* imply that various other drivers in
> drivers/crypto/ don't have similar issues.  They do.  Rather, the
> evidence is just exceptionally clear for this one, in part because
> hardware availability has enabled independent testing.
> 
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH] crypto: qce - Remove driver

[Bartosz Golaszewski]

On Fri, 24 Jul 2026 07:28:53 +0200, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> said:
> On Thu, Jul 23, 2026 at 10:06:45PM -0700, Eric Biggers wrote:
>> This obsolete driver was already marked as BROKEN.  However, keeping
>> BROKEN code around in the tree is unnecessary and causes problems.  It's
>> much better to just remove it entirely.  Let's do that.
>>
>> Crypto acceleration remains well-supported on Qualcomm SoCs via the
>> Qualcomm Inline Crypto Engine and the ARMv8 Crypto Extensions, which are
>> what Linux actually uses in practice.  The obsolete QCE driver is a
>> dead-end approach.  It's extremely slow and just doesn't work well.
>>
>> While there's been discussion around using QCE for restricted media
>> content protection, that functionality has very little to do with the
>> current crypto API driver and belongs in a separate, clean proposal
>> (likely under a different subsystem/directory).
>>
>> The extensive reasons for marking this driver as BROKEN were already
>> documented in commit df373d39c6f0 ("crypto: qce - Mark QCE as BROKEN").
>>
>> Since then, it's also been found that under realistic workloads, the
>> driver is not only ~48x slower than ARMv8 CE, but due to massive driver
>> overhead it actually consumes significantly *more* CPU cycles than doing
>> the hashing directly on the CPU -- with much of that time spent in
>> non-preemptible hardirq and softirq contexts
>> (https://lore.kernel.org/linux-crypto/20260724020608.GA51735@sol/).  The
>> proposed BAM locking fixes would only further degrade performance.
>>
>> Additional bugs have been found as well
>> (https://lore.kernel.org/linux-crypto/20260723205801.GD110634@quark/).
>> Pending fixes for some bugs don't change the big picture.  Nor have
>> security-related claims held up.  Of course, these issues are largely
>> moot anyway when this driver's functionality isn't being used in
>> practice, beyond the module loading due to it being in the kconfig.
>>
>> Note that this removal does *not* imply that various other drivers in
>> drivers/crypto/ don't have similar issues.  They do.  Rather, the
>> evidence is just exceptionally clear for this one, in part because
>> hardware availability has enabled independent testing.
>>
>> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>

Greg,

I'm against removing this driver but I have a kernel driver policy question
before I start arguing the case: If I say that I do use this driver and that
I volunteer to maintain it and had already started sending out fixes, can
Eric still force its removal? Because in this case I can name a whole lot of
drivers that I deem useless that we still keep around.

The alg priority of this driver has been decreased below that of ARM CE and
since CRYPTO_ALG_KERN_DRIVER_ONLY it can no longer be used accidentally by
user-space either.

Even if in practice the driver is used for testing purposes - does this warrant
its removal?

Thanks,
Bartosz