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

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

[Demi Marie Obenour via B4 Relay]

From: Demi Marie Obenour <demiobenour@gmail.com>

This driver is harmful:

- It is much slower than the CPU [1] [2].
- It Has a history of bugs [2] [3].
- It does not have exclusive access to the hardware [4], causing races
  with the secure world.
- It register its implementations with too low a cra_priority for them
  to be actually used [5].

Therefore, disable it to ensure that nobody builds it into kernels they
intend to ship.

In the future, the driver will be used for processing restricted media
content.  However, the kernel does not currently support this.  Since
the driver will have future uses, allow building it if COMPILE_TEST is
enabled.

[1]: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
[2]: https://lore.kernel.org/r/20250615031807.GA81869@sol/
[3]: https://lore.kernel.org/r/20260706-qce-fix-self-tests-v5-0-86f461ff1829@oss.qualcomm.com/
[4]: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-0-56f67da84c05@oss.qualcomm.com/
[5]: https://lore.kernel.org/r/20260524204537.GB110177@quark/

Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
---
Changes in v2:
- Add Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver")
- Add Cc: stable@vger.kernel.org
- Link to v1: https://lore.kernel.org/r/20260712-qce-broken-v1-1-85e2bff17871@gmail.com
---
 arch/arm/configs/multi_v7_defconfig | 1 -
 arch/arm64/configs/defconfig        | 1 -
 drivers/crypto/Kconfig              | 6 +++++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 01e016752c4d425e59a1a499abb8df8845aa9833..13d85a0e8580000235b4dbf6d0911b4e09af199d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1321,7 +1321,6 @@ CONFIG_CRYPTO_DEV_ATMEL_AES=m
 CONFIG_CRYPTO_DEV_ATMEL_TDES=m
 CONFIG_CRYPTO_DEV_ATMEL_SHA=m
 CONFIG_CRYPTO_DEV_MARVELL_CESA=m
-CONFIG_CRYPTO_DEV_QCE=m
 CONFIG_CRYPTO_DEV_ROCKCHIP=m
 CONFIG_CRYPTO_DEV_STM32_HASH=m
 CONFIG_CRYPTO_DEV_STM32_CRYP=m
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 76ce07a08d5ac45bc4a4890c3f1aa7391de346fd..c624cdd122d144ad7e052f965c20c9bdcb3bd2e1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1940,7 +1940,6 @@ CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
 CONFIG_CRYPTO_DEV_SUN8I_CE=m
 CONFIG_CRYPTO_DEV_FSL_CAAM=m
 CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=m
-CONFIG_CRYPTO_DEV_QCE=m
 CONFIG_CRYPTO_DEV_TEGRA=m
 CONFIG_CRYPTO_DEV_ZYNQMP_AES=m
 CONFIG_CRYPTO_DEV_ZYNQMP_SHA3=m
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 03a8f7a1f75e878846dcf34da1265828949fbd9c..0189dfdcbbe11098ead0ea194293422a31d8fe65 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -528,13 +528,17 @@ source "drivers/crypto/intel/Kconfig"
 
 config CRYPTO_DEV_QCE
 	tristate "Qualcomm crypto engine accelerator"
-	depends on ARCH_QCOM || COMPILE_TEST
+	depends on (BROKEN && ARCH_QCOM) || COMPILE_TEST
 	depends on HAS_IOMEM
 	help
 	  This driver supports Qualcomm crypto engine accelerator
 	  hardware. To compile this driver as a module, choose M here. The
 	  module will be called qcrypto.
 
+	  This driver does not have exclusive access to the
+	  hardware, causing races with the secure world.  It
+	  is also slower than the CPU.
+
 config CRYPTO_DEV_QCE_SKCIPHER
 	bool
 	depends on CRYPTO_DEV_QCE

---
base-commit: e264401ce4776a288524e5b87593d4d864147115
change-id: 20260712-qce-broken-6035863c14a0

Best regards,
-- 
Demi Marie Obenour <demiobenour@gmail.com>

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

[Eric Biggers]

On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
> From: Demi Marie Obenour <demiobenour@gmail.com>
> 
> This driver is harmful:
> 
> - It is much slower than the CPU [1] [2].
> - It Has a history of bugs [2] [3].
> - It does not have exclusive access to the hardware [4], causing races
>   with the secure world.
> - It register its implementations with too low a cra_priority for them
>   to be actually used [5].
> 
> Therefore, disable it to ensure that nobody builds it into kernels they
> intend to ship.
> 
> In the future, the driver will be used for processing restricted media
> content.  However, the kernel does not currently support this.  Since
> the driver will have future uses, allow building it if COMPILE_TEST is
> enabled.
> 
> [1]: https://lore.kernel.org/r/20250704070322.20692-1-ebiggers@kernel.org/
> [2]: https://lore.kernel.org/r/20250615031807.GA81869@sol/
> [3]: https://lore.kernel.org/r/20260706-qce-fix-self-tests-v5-0-86f461ff1829@oss.qualcomm.com/
> [4]: https://lore.kernel.org/r/20260629-qcom-qce-cmd-descr-v20-0-56f67da84c05@oss.qualcomm.com/
> [5]: https://lore.kernel.org/r/20260524204537.GB110177@quark/
> 
> Fixes: ec8f5d8f6f76 ("crypto: qce - Qualcomm crypto engine driver")
> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>

Acked-by: Eric Biggers <ebiggers@kernel.org>

- Eric

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

[Greg KH]

On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
> From: Demi Marie Obenour <demiobenour@gmail.com>
> 
> This driver is harmful:
> 
> - It is much slower than the CPU [1] [2].
> - It Has a history of bugs [2] [3].
> - It does not have exclusive access to the hardware [4], causing races
>   with the secure world.
> - It register its implementations with too low a cra_priority for them
>   to be actually used [5].
> 
> Therefore, disable it to ensure that nobody builds it into kernels they
> intend to ship.
> 
> In the future, the driver will be used for processing restricted media
> content.  However, the kernel does not currently support this.  Since
> the driver will have future uses, allow building it if COMPILE_TEST is
> enabled.

Why not just delete it now, and then bring it back when it is needed in
the future?  Otherwise this will just trip up the static code checkers
who will attempt to "fix" things in it.

thanks,

greg k-h

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

[Eric Biggers]

On Mon, Jul 13, 2026 at 06:47:07AM +0200, Greg KH wrote:
> On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
> > From: Demi Marie Obenour <demiobenour@gmail.com>
> > 
> > This driver is harmful:
> > 
> > - It is much slower than the CPU [1] [2].
> > - It Has a history of bugs [2] [3].
> > - It does not have exclusive access to the hardware [4], causing races
> >   with the secure world.
> > - It register its implementations with too low a cra_priority for them
> >   to be actually used [5].
> > 
> > Therefore, disable it to ensure that nobody builds it into kernels they
> > intend to ship.
> > 
> > In the future, the driver will be used for processing restricted media
> > content.  However, the kernel does not currently support this.  Since
> > the driver will have future uses, allow building it if COMPILE_TEST is
> > enabled.
> 
> Why not just delete it now, and then bring it back when it is needed in
> the future?  Otherwise this will just trip up the static code checkers
> who will attempt to "fix" things in it.

That makes sense to me, but Qualcomm pushed back on deletion:
https://lore.kernel.org/linux-crypto/20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com/

But I've still not seen any evidence that this driver is useful for
anything or has any users.  Even Qualcomm seems to be unwilling to make
such claims; they only claim that the IP is used (i.e., not in Linux)
and that new features are planned.

- Eric

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

[Greg KH]

On Mon, Jul 13, 2026 at 09:07:45AM -0400, Eric Biggers wrote:
> On Mon, Jul 13, 2026 at 06:47:07AM +0200, Greg KH wrote:
> > On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
> > > From: Demi Marie Obenour <demiobenour@gmail.com>
> > > 
> > > This driver is harmful:
> > > 
> > > - It is much slower than the CPU [1] [2].
> > > - It Has a history of bugs [2] [3].
> > > - It does not have exclusive access to the hardware [4], causing races
> > >   with the secure world.
> > > - It register its implementations with too low a cra_priority for them
> > >   to be actually used [5].
> > > 
> > > Therefore, disable it to ensure that nobody builds it into kernels they
> > > intend to ship.
> > > 
> > > In the future, the driver will be used for processing restricted media
> > > content.  However, the kernel does not currently support this.  Since
> > > the driver will have future uses, allow building it if COMPILE_TEST is
> > > enabled.
> > 
> > Why not just delete it now, and then bring it back when it is needed in
> > the future?  Otherwise this will just trip up the static code checkers
> > who will attempt to "fix" things in it.
> 
> That makes sense to me, but Qualcomm pushed back on deletion:
> https://lore.kernel.org/linux-crypto/20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com/
> 
> But I've still not seen any evidence that this driver is useful for
> anything or has any users.  Even Qualcomm seems to be unwilling to make
> such claims; they only claim that the IP is used (i.e., not in Linux)
> and that new features are planned.

Well we don't normally have drivers that are marked as BROKEN just
laying around in the tree these days, especially given that a LLM is
bound to do a drive-by and find lots of issues that people will not
realize doesn't matter given that the code is never actually built.

But hey, it's not my subsystem, if you want to keep it here, fine with
me, just asking :)

thanks,

greg k-h

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2019 bytes --]

On 7/13/26 09:07, Eric Biggers wrote:
> On Mon, Jul 13, 2026 at 06:47:07AM +0200, Greg KH wrote:
>> On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
>>> From: Demi Marie Obenour <demiobenour@gmail.com>
>>>
>>> This driver is harmful:
>>>
>>> - It is much slower than the CPU [1] [2].
>>> - It Has a history of bugs [2] [3].
>>> - It does not have exclusive access to the hardware [4], causing races
>>>   with the secure world.
>>> - It register its implementations with too low a cra_priority for them
>>>   to be actually used [5].
>>>
>>> Therefore, disable it to ensure that nobody builds it into kernels they
>>> intend to ship.
>>>
>>> In the future, the driver will be used for processing restricted media
>>> content.  However, the kernel does not currently support this.  Since
>>> the driver will have future uses, allow building it if COMPILE_TEST is
>>> enabled.
>>
>> Why not just delete it now, and then bring it back when it is needed in
>> the future?  Otherwise this will just trip up the static code checkers
>> who will attempt to "fix" things in it.
> 
> That makes sense to me, but Qualcomm pushed back on deletion:
> https://lore.kernel.org/linux-crypto/20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com/
> 
> But I've still not seen any evidence that this driver is useful for
> anything or has any users.  Even Qualcomm seems to be unwilling to make
> such claims; they only claim that the IP is used (i.e., not in Linux)
> and that new features are planned.
> 
> - Eric

Here is my reading of Qualcomm's statements:

QCE is currently used by the Arm secure world.  In the future, QCE
will be used by the kernel as part of restricted content playback.
Qualcomm wants to add the needed features to the existing driver.
This will not use the crypto API.

I would be fine with the driver being removed, but not if it means
another out-of-tree Android driver.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Greg KH]

On Mon, Jul 13, 2026 at 10:42:04AM -0400, Demi Marie Obenour wrote:
> On 7/13/26 09:07, Eric Biggers wrote:
> > On Mon, Jul 13, 2026 at 06:47:07AM +0200, Greg KH wrote:
> >> On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
> >>> From: Demi Marie Obenour <demiobenour@gmail.com>
> >>>
> >>> This driver is harmful:
> >>>
> >>> - It is much slower than the CPU [1] [2].
> >>> - It Has a history of bugs [2] [3].
> >>> - It does not have exclusive access to the hardware [4], causing races
> >>>   with the secure world.
> >>> - It register its implementations with too low a cra_priority for them
> >>>   to be actually used [5].
> >>>
> >>> Therefore, disable it to ensure that nobody builds it into kernels they
> >>> intend to ship.
> >>>
> >>> In the future, the driver will be used for processing restricted media
> >>> content.  However, the kernel does not currently support this.  Since
> >>> the driver will have future uses, allow building it if COMPILE_TEST is
> >>> enabled.
> >>
> >> Why not just delete it now, and then bring it back when it is needed in
> >> the future?  Otherwise this will just trip up the static code checkers
> >> who will attempt to "fix" things in it.
> > 
> > That makes sense to me, but Qualcomm pushed back on deletion:
> > https://lore.kernel.org/linux-crypto/20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com/
> > 
> > But I've still not seen any evidence that this driver is useful for
> > anything or has any users.  Even Qualcomm seems to be unwilling to make
> > such claims; they only claim that the IP is used (i.e., not in Linux)
> > and that new features are planned.
> > 
> > - Eric
> 
> Here is my reading of Qualcomm's statements:
> 
> QCE is currently used by the Arm secure world.  In the future, QCE
> will be used by the kernel as part of restricted content playback.
> Qualcomm wants to add the needed features to the existing driver.
> This will not use the crypto API.

Why is a crypto driver not going to use the crypto API?

> I would be fine with the driver being removed, but not if it means
> another out-of-tree Android driver.

It's not another out-of-tree Android driver if nothing in Android
actually uses it :)

thanks,

greg k-h

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2631 bytes --]

On 7/13/26 11:31, Greg KH wrote:
> On Mon, Jul 13, 2026 at 10:42:04AM -0400, Demi Marie Obenour wrote:
>> On 7/13/26 09:07, Eric Biggers wrote:
>>> On Mon, Jul 13, 2026 at 06:47:07AM +0200, Greg KH wrote:
>>>> On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
>>>>> From: Demi Marie Obenour <demiobenour@gmail.com>
>>>>>
>>>>> This driver is harmful:
>>>>>
>>>>> - It is much slower than the CPU [1] [2].
>>>>> - It Has a history of bugs [2] [3].
>>>>> - It does not have exclusive access to the hardware [4], causing races
>>>>>   with the secure world.
>>>>> - It register its implementations with too low a cra_priority for them
>>>>>   to be actually used [5].
>>>>>
>>>>> Therefore, disable it to ensure that nobody builds it into kernels they
>>>>> intend to ship.
>>>>>
>>>>> In the future, the driver will be used for processing restricted media
>>>>> content.  However, the kernel does not currently support this.  Since
>>>>> the driver will have future uses, allow building it if COMPILE_TEST is
>>>>> enabled.
>>>>
>>>> Why not just delete it now, and then bring it back when it is needed in
>>>> the future?  Otherwise this will just trip up the static code checkers
>>>> who will attempt to "fix" things in it.
>>>
>>> That makes sense to me, but Qualcomm pushed back on deletion:
>>> https://lore.kernel.org/linux-crypto/20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com/
>>>
>>> But I've still not seen any evidence that this driver is useful for
>>> anything or has any users.  Even Qualcomm seems to be unwilling to make
>>> such claims; they only claim that the IP is used (i.e., not in Linux)
>>> and that new features are planned.
>>>
>>> - Eric
>>
>> Here is my reading of Qualcomm's statements:
>>
>> QCE is currently used by the Arm secure world.  In the future, QCE
>> will be used by the kernel as part of restricted content playback.
>> Qualcomm wants to add the needed features to the existing driver.
>> This will not use the crypto API.
> 
> Why is a crypto driver not going to use the crypto API?

I suspect that the restricted content playback use-case involves
QCE decrypting data stored in kernel memory, using keys inaccessible
to the kernel, to memory inaccessible to the kernel.  The crypto API
can't express this.

>> I would be fine with the driver being removed, but not if it means
>> another out-of-tree Android driver.
> 
> It's not another out-of-tree Android driver if nothing in Android
> actually uses it :)

Nothing uses it *yet*.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 2929 bytes --]

On 7/13/26 15:49, Demi Marie Obenour wrote:
> On 7/13/26 11:31, Greg KH wrote:
>> On Mon, Jul 13, 2026 at 10:42:04AM -0400, Demi Marie Obenour wrote:
>>> On 7/13/26 09:07, Eric Biggers wrote:
>>>> On Mon, Jul 13, 2026 at 06:47:07AM +0200, Greg KH wrote:
>>>>> On Sun, Jul 12, 2026 at 05:31:31PM -0400, Demi Marie Obenour via B4 Relay wrote:
>>>>>> From: Demi Marie Obenour <demiobenour@gmail.com>
>>>>>>
>>>>>> This driver is harmful:
>>>>>>
>>>>>> - It is much slower than the CPU [1] [2].
>>>>>> - It Has a history of bugs [2] [3].
>>>>>> - It does not have exclusive access to the hardware [4], causing races
>>>>>>   with the secure world.
>>>>>> - It register its implementations with too low a cra_priority for them
>>>>>>   to be actually used [5].
>>>>>>
>>>>>> Therefore, disable it to ensure that nobody builds it into kernels they
>>>>>> intend to ship.
>>>>>>
>>>>>> In the future, the driver will be used for processing restricted media
>>>>>> content.  However, the kernel does not currently support this.  Since
>>>>>> the driver will have future uses, allow building it if COMPILE_TEST is
>>>>>> enabled.
>>>>>
>>>>> Why not just delete it now, and then bring it back when it is needed in
>>>>> the future?  Otherwise this will just trip up the static code checkers
>>>>> who will attempt to "fix" things in it.
>>>>
>>>> That makes sense to me, but Qualcomm pushed back on deletion:
>>>> https://lore.kernel.org/linux-crypto/20260602-qcom-qce-broken-v1-1-a4ef756089e0@oss.qualcomm.com/
>>>>
>>>> But I've still not seen any evidence that this driver is useful for
>>>> anything or has any users.  Even Qualcomm seems to be unwilling to make
>>>> such claims; they only claim that the IP is used (i.e., not in Linux)
>>>> and that new features are planned.
>>>>
>>>> - Eric
>>>
>>> Here is my reading of Qualcomm's statements:
>>>
>>> QCE is currently used by the Arm secure world.  In the future, QCE
>>> will be used by the kernel as part of restricted content playback.
>>> Qualcomm wants to add the needed features to the existing driver.
>>> This will not use the crypto API.
>>
>> Why is a crypto driver not going to use the crypto API?
> 
> I suspect that the restricted content playback use-case involves
> QCE decrypting data stored in kernel memory, using keys inaccessible
> to the kernel, to memory inaccessible to the kernel.  The crypto API
> can't express this.
> 
>>> I would be fine with the driver being removed, but not if it means
>>> another out-of-tree Android driver.
>>
>> It's not another out-of-tree Android driver if nothing in Android
>> actually uses it :)
> 
> Nothing uses it *yet*.

That said, deleting the driver is also an option.  I don't have a
problem with that myself, but Qualcomm does.  I figured that
marking the driver BROKEN would be less objectionable.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]