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

Re: [PATCH] crypto: qce - Remove driver

[Greg Kroah-Hartman]

On Fri, Jul 24, 2026 at 12:36:24AM -0700, Bartosz Golaszewski wrote:
> 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.

But you aren't using it if it is marked as BROKEN.  If that's not the
case, and it is not broken, well why is it marked that way?

> 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.

If it can't be used, then again, who is using it?  We can't have ONLY
out of tree users for code that is in the kernel.  We HAVE to have
in-kernel users for it to stick around.

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

testing purposes of what exactly if there is no in-kernel code that
calls this thing?

thanks,

greg k-h

Re: [PATCH] crypto: qce - Remove driver

[Bartosz Golaszewski]

On Fri, Jul 24, 2026 at 10:42 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 24, 2026 at 12:36:24AM -0700, Bartosz Golaszewski wrote:
> > 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.
>
> But you aren't using it if it is marked as BROKEN.  If that's not the
> case, and it is not broken, well why is it marked that way?
>

It was marked as BROKEN only a couple of days ago (it hasn't been
released as BROKEN in any upstream tag yet) despite my NAK, making
myself the maintainer for this driver and having sent the first set of
fixes addressing crypto self-tests failures. There's a bit more
context here. :)

> > 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.
>
> If it can't be used, then again, who is using it?  We can't have ONLY
> out of tree users for code that is in the kernel.  We HAVE to have
> in-kernel users for it to stick around.
>

It can't be used *accidentally*. It can still be used by in-kernel
users if you bump its priority via netlink.

> > Even if in practice the driver is used for testing purposes - does this warrant
> > its removal?
>
> testing purposes of what exactly if there is no in-kernel code that
> calls this thing?
>

Of several of the crypto accelerator IP's functionalities. But that's
just an example. We do use it - I was just asking if if we use a
kernel module to test HW functionality of an IP - is this enough of a
reason to keep its driver, not taking into account things like FIPS
140/3 certifications, etc.

Bartosz