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

Re: [PATCH] crypto: qce - Remove driver

[Eric Biggers]

On Fri, Jul 24, 2026 at 11:29:30AM +0200, Bartosz Golaszewski wrote:
> It can't be used *accidentally*. It can still be used by in-kernel
> users if you bump its priority via netlink.

dm-verity, fscrypt, fsverity, and blk-crypto-fallback don't support this
driver.  The QCE driver itself has bugs that make it not work with
dm-crypt and IPsec.

That's all regardless of any theoretical tweaking via NETLINK_CRYPTO.

That doesn't leave many upstream kernel features that could even
*theoretically* be using the QCE driver if someone were to do the
NETLINK_CRYPTO thing.  Maybe SMB or kTLS?  (But not with AES-GCM, as the
QCE driver doesn't support AES-GCM.  It would have to be AES-CCM.)

However, over the years it's become extremely clear that virtually no
one actually uses NETLINK_CRYPTO to tweak the algorithm priorities.

It's part of the excessive "flexibility" of the crypto framework that is
just not used in practice.  Users actually just use the defaults.

And with the defaults QCE is *never* used.

So I think the NETLINK_CRYPTO thing is a red herring.  There's just no
credible upstream use case justifying this driver's retention.

- Eric

Re: [PATCH] crypto: qce - Remove driver

[Bartosz Golaszewski]

On Fri, 24 Jul 2026 16:14:14 +0200, Eric Biggers <ebiggers@kernel.org> said:
>
> And with the defaults QCE is *never* used.
>

It's almost EOD here and I'm going to disconnect for the weekend but I just
wanted to say before I leave: this has never been a reason for an aggresive
removal of any driver. We remove drivers when we stop supporting entire
platforms, not mostly unused drivers on actively *supported* platforms where
they can still be used for experimentation and testing. I'm fine with dropping
this from arm64 defconfig but with fixes, the BROKEN tag should be removed
and I definitely object to removing it from the tree. How many people still
use greybus? Should we drop it from the kernel too? And I'm saying it as
a project ARA alumni. :)

Let's pick it up next week.

Thanks,
Bartosz

Re: [PATCH] crypto: qce - Remove driver

[Greg Kroah-Hartman]

On Fri, Jul 24, 2026 at 02:47:48PM +0000, Bartosz Golaszewski wrote:
> On Fri, 24 Jul 2026 16:14:14 +0200, Eric Biggers <ebiggers@kernel.org> said:
> >
> > And with the defaults QCE is *never* used.
> >
> 
> It's almost EOD here and I'm going to disconnect for the weekend but I just
> wanted to say before I leave: this has never been a reason for an aggresive
> removal of any driver. We remove drivers when we stop supporting entire
> platforms, not mostly unused drivers on actively *supported* platforms where
> they can still be used for experimentation and testing. I'm fine with dropping
> this from arm64 defconfig but with fixes, the BROKEN tag should be removed
> and I definitely object to removing it from the tree. How many people still
> use greybus? Should we drop it from the kernel too? And I'm saying it as
> a project ARA alumni. :)

I agree, if someone is willing to maintain it, and there are actual
in-kernel uses of it (meaning not just a stand-alone library that can
never be called either by userspace or hardware), it should stay.

thanks,

greg k-h

Re: [PATCH] crypto: qce - Remove driver

[Eric Biggers]

On Fri, Jul 24, 2026 at 05:04:46PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 24, 2026 at 02:47:48PM +0000, Bartosz Golaszewski wrote:
> > On Fri, 24 Jul 2026 16:14:14 +0200, Eric Biggers <ebiggers@kernel.org> said:
> > >
> > > And with the defaults QCE is *never* used.
> > >
> > 
> > It's almost EOD here and I'm going to disconnect for the weekend but I just
> > wanted to say before I leave: this has never been a reason for an aggresive
> > removal of any driver. We remove drivers when we stop supporting entire
> > platforms, not mostly unused drivers on actively *supported* platforms where
> > they can still be used for experimentation and testing. I'm fine with dropping
> > this from arm64 defconfig but with fixes, the BROKEN tag should be removed
> > and I definitely object to removing it from the tree. How many people still
> > use greybus? Should we drop it from the kernel too? And I'm saying it as
> > a project ARA alumni. :)
> 
> I agree, if someone is willing to maintain it, and there are actual
> in-kernel uses of it (meaning not just a stand-alone library that can
> never be called either by userspace or hardware), it should stay.

What would we be considering the in-kernel uses to be, then?  Just
wiring it up to the framework is enough, regardless of actual use?

- Eric

Re: [PATCH] crypto: qce - Remove driver

[Greg Kroah-Hartman]

On Fri, Jul 24, 2026 at 08:09:32AM -0700, Eric Biggers wrote:
> On Fri, Jul 24, 2026 at 05:04:46PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jul 24, 2026 at 02:47:48PM +0000, Bartosz Golaszewski wrote:
> > > On Fri, 24 Jul 2026 16:14:14 +0200, Eric Biggers <ebiggers@kernel.org> said:
> > > >
> > > > And with the defaults QCE is *never* used.
> > > >
> > > 
> > > It's almost EOD here and I'm going to disconnect for the weekend but I just
> > > wanted to say before I leave: this has never been a reason for an aggresive
> > > removal of any driver. We remove drivers when we stop supporting entire
> > > platforms, not mostly unused drivers on actively *supported* platforms where
> > > they can still be used for experimentation and testing. I'm fine with dropping
> > > this from arm64 defconfig but with fixes, the BROKEN tag should be removed
> > > and I definitely object to removing it from the tree. How many people still
> > > use greybus? Should we drop it from the kernel too? And I'm saying it as
> > > a project ARA alumni. :)
> > 
> > I agree, if someone is willing to maintain it, and there are actual
> > in-kernel uses of it (meaning not just a stand-alone library that can
> > never be called either by userspace or hardware), it should stay.
> 
> What would we be considering the in-kernel uses to be, then?  Just
> wiring it up to the framework is enough, regardless of actual use?

I was meaning that we just don't want to have code lying around that is
impossible to use.

I'll defer to the subsystem maintainer if they want to remove it or not
here, as that's their call, not mine.

But really, if someone wants to maintain it, no matter how slow it might
be, I don't see the harm in keeping it if it's not causing any other
problems.

thanks,

greg k-h

Re: [PATCH] crypto: qce - Remove driver

[Eric Biggers]

On Fri, Jul 24, 2026 at 05:25:46PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 24, 2026 at 08:09:32AM -0700, Eric Biggers wrote:
> > On Fri, Jul 24, 2026 at 05:04:46PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jul 24, 2026 at 02:47:48PM +0000, Bartosz Golaszewski wrote:
> > > > On Fri, 24 Jul 2026 16:14:14 +0200, Eric Biggers <ebiggers@kernel.org> said:
> > > > >
> > > > > And with the defaults QCE is *never* used.
> > > > >
> > > > 
> > > > It's almost EOD here and I'm going to disconnect for the weekend but I just
> > > > wanted to say before I leave: this has never been a reason for an aggresive
> > > > removal of any driver. We remove drivers when we stop supporting entire
> > > > platforms, not mostly unused drivers on actively *supported* platforms where
> > > > they can still be used for experimentation and testing. I'm fine with dropping
> > > > this from arm64 defconfig but with fixes, the BROKEN tag should be removed
> > > > and I definitely object to removing it from the tree. How many people still
> > > > use greybus? Should we drop it from the kernel too? And I'm saying it as
> > > > a project ARA alumni. :)
> > > 
> > > I agree, if someone is willing to maintain it, and there are actual
> > > in-kernel uses of it (meaning not just a stand-alone library that can
> > > never be called either by userspace or hardware), it should stay.
> > 
> > What would we be considering the in-kernel uses to be, then?  Just
> > wiring it up to the framework is enough, regardless of actual use?
> 
> I was meaning that we just don't want to have code lying around that is
> impossible to use.
> 
> I'll defer to the subsystem maintainer if they want to remove it or not
> here, as that's their call, not mine.
> 
> But really, if someone wants to maintain it, no matter how slow it might
> be, I don't see the harm in keeping it if it's not causing any other
> problems.

It is consuming a lot of the community's time to help maintain,
including dealing with LLM-found bugs, with no clear benefit to anyone.
Even considering *just today* we can see someone sent a bug fix:
https://lore.kernel.org/linux-crypto/20260724081537.191992-2-thorsten.blum@linux.dev/

It definitely *was* causing problems before it was disabled via the
crypto priority system (which made it unused in the kernel) and dropped
it from AF_ALG (which removed most of the unprivileged attack surface).
When anyone accidentally used it, it caused at least a huge performance
problem, and sometimes other problems too like filesystem hangs.  It was
an issue for years.

If the justification for keeping it is that it is disabled anyway, then
I hope there's not going to be a contradictory push to enable it again.

I don't think we should keep crypto drivers around just for
"experimentation and testing".

- Eric

Re: [PATCH] crypto: qce - Remove driver

[Eric Biggers]

On Fri, Jul 24, 2026 at 03:26:41PM +0530, Sumit Garg wrote:
> Hi Eric,
> 
> 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.
> 
> Not sure why only performance is seen as the major driver to drop crypto
> accelerators from kernel

Maybe you missed all the other reasons I gave too.

> while neglecting the security use-cases they support as well like:
> 
> - Support for hardware backed keys
> - Support for secure media playback use-cases

The QCE driver doesn't support these features.  So they aren't relevant
to this patch.

> I know it's not good to add functionality based on a prospective
> future use-cases but at the same time dropping functionality for it to be
> added again is just too much unnecessary churn.

This conflates current functionality, which doesn't meet upstream kernel
inclusion standards, with mostly-unrelated speculative future
functionality.  Anything new should just start from a clean slate with
just what is actually needed.

> I am sure you are aware about support for hardware backed key use-cases
> for many of those crypto accelerators. NXP CAAM engine is one such
> example.

The CAAM driver does register a "cbc(paes)" algorithm with the crypto
API (i.e., CBC-AES with a hardware backed key).  However, there's no
upstream user of that algorithm as far as I can tell.

But this is unrelated to this patch, which is for the QCE driver.

- Eric