[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 --]

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

[Herbert Xu]

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>
> ---
> 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(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Bartosz Golaszewski]

On Fri, Jul 17, 2026 at 06:18:48PM +1000, Herbert Xu 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.
> >
> > [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(-)
>
> Patch applied.  Thanks.

Hi Herbert,

I'd like to ask you to back this patch out. Admittedly I should have NAKed this
under the v1 thread but I thought the discussion we had under the Shikra series
and the subsequent patch making myself the maintainer of this driver (note: Demi
did not Cc me on this nor the Qcom mailing list at linux-arm-msm) as well as the
pending series[1] fixing the QCE issues was enough to imply we should not mark
it as broken. Please consider applying [1] if the fixes in v6 are correct.

Bartosz

[1] https://lore.kernel.org/all/20260717-qce-fix-self-tests-v6-0-455775fe5f6c@oss.qualcomm.com/

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

[Demi Marie Obenour]

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

On 7/21/26 04:24, Bartosz Golaszewski wrote:
> On Fri, Jul 17, 2026 at 06:18:48PM +1000, Herbert Xu 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.
>>>
>>> [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(-)
>>
>> Patch applied.  Thanks.
> 
> Hi Herbert,
> 
> I'd like to ask you to back this patch out. Admittedly I should have NAKed this
> under the v1 thread but I thought the discussion we had under the Shikra series
> and the subsequent patch making myself the maintainer of this driver (note: Demi
> did not Cc me on this nor the Qcom mailing list at linux-arm-msm) as well as the
> pending series[1] fixing the QCE issues was enough to imply we should not mark
> it as broken. Please consider applying [1] if the fixes in v6 are correct.
> 
> Bartosz
> 
> [1] https://lore.kernel.org/all/20260717-qce-fix-self-tests-v6-0-455775fe5f6c@oss.qualcomm.com/

Is the BAM locking patchset also needed?  My understanding is that
without it, the QCE driver can still produce wrong results due to races
with the TrustZone firmware.  Until it is merged and the self-tests
are fixed, the driver definitely needs to be marked BROKEN.

Also, what can the current driver do that cannot be done better using
software crypto?  I understand that you have future plans to add more
features to the driver, but those are not relevant to this discussion.

Finally, I very much appreciate the work you have done.  I don't
expect that the QCE driver will stay BROKEN forever.  This patch is
purely a reflection of the current state of the driver, the speed of
CPU-accelerated crypto, and the small message sizes used by the kernel.

That said, is drivers/crypto really the right place for a restricted
content driver?  A driver that uses dmabufs might be a better
alternative, and would be easier to integrate with the Direct Rendering
Manager (DRM) and Video for Linux 2 (V4L2) subsystems.
-- 
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

[Bartosz Golaszewski]

On Tue, 21 Jul 2026 20:29:39 +0200, Demi Marie Obenour
<demiobenour@gmail.com> said:
> On 7/21/26 04:24, Bartosz Golaszewski wrote:
>> On Fri, Jul 17, 2026 at 06:18:48PM +1000, Herbert Xu 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.
>>>>
>>>> [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(-)
>>>
>>> Patch applied.  Thanks.
>>
>> Hi Herbert,
>>
>> I'd like to ask you to back this patch out. Admittedly I should have NAKed this
>> under the v1 thread but I thought the discussion we had under the Shikra series
>> and the subsequent patch making myself the maintainer of this driver (note: Demi
>> did not Cc me on this nor the Qcom mailing list at linux-arm-msm) as well as the
>> pending series[1] fixing the QCE issues was enough to imply we should not mark
>> it as broken. Please consider applying [1] if the fixes in v6 are correct.
>>
>> Bartosz
>>
>> [1] https://lore.kernel.org/all/20260717-qce-fix-self-tests-v6-0-455775fe5f6c@oss.qualcomm.com/
>
> Is the BAM locking patchset also needed?  My understanding is that
> without it, the QCE driver can still produce wrong results due to races
> with the TrustZone firmware.  Until it is merged and the self-tests
> are fixed, the driver definitely needs to be marked BROKEN.
>

No, we currently don't ship TZ firmware that could cause such interactions.
The only driver that currently suffers from such races is the NAND driver
which races with the modem firmware and it too will use the BAM locking
feature once it's upstream. However we do plan to support DRM using this IP
and this is when it'll need to account for possible races. IOW: BAM locking
is not strictly required to fix the QCE.

> Also, what can the current driver do that cannot be done better using
> software crypto?  I understand that you have future plans to add more
> features to the driver, but those are not relevant to this discussion.
>

We can offload crypto operations to the QCE saving CPU cycles but more
importantly, the QCE provides HW based isolation which some vendors care
about.

> Finally, I very much appreciate the work you have done.  I don't
> expect that the QCE driver will stay BROKEN forever.  This patch is
> purely a reflection of the current state of the driver, the speed of
> CPU-accelerated crypto, and the small message sizes used by the kernel.
>

That may have been true when you sent the v1 but with a set of proposed fixes
it'll no longer be the case.

> That said, is drivers/crypto really the right place for a restricted
> content driver?  A driver that uses dmabufs might be a better
> alternative, and would be easier to integrate with the Direct Rendering
> Manager (DRM) and Video for Linux 2 (V4L2) subsystems.
> --

These are future plans, yes. But right now we do have active users of this
IP and now also a maintainer - yours truly - who stepped up and is actively
working on this module. With the fixes applied, the driver will again pass
crypto self-tests and should not be BROKEN.

Thanks,
Bartosz

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

[Demi Marie Obenour]

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

On 7/22/26 04:33, Bartosz Golaszewski wrote:
> On Tue, 21 Jul 2026 20:29:39 +0200, Demi Marie Obenour
> <demiobenour@gmail.com> said:
>> On 7/21/26 04:24, Bartosz Golaszewski wrote:
>>> On Fri, Jul 17, 2026 at 06:18:48PM +1000, Herbert Xu 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.
>>>>>
>>>>> [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(-)
>>>>
>>>> Patch applied.  Thanks.
>>>
>>> Hi Herbert,
>>>
>>> I'd like to ask you to back this patch out. Admittedly I should have NAKed this
>>> under the v1 thread but I thought the discussion we had under the Shikra series
>>> and the subsequent patch making myself the maintainer of this driver (note: Demi
>>> did not Cc me on this nor the Qcom mailing list at linux-arm-msm) as well as the
>>> pending series[1] fixing the QCE issues was enough to imply we should not mark
>>> it as broken. Please consider applying [1] if the fixes in v6 are correct.
>>>
>>> Bartosz
>>>
>>> [1] https://lore.kernel.org/all/20260717-qce-fix-self-tests-v6-0-455775fe5f6c@oss.qualcomm.com/
>>
>> Is the BAM locking patchset also needed?  My understanding is that
>> without it, the QCE driver can still produce wrong results due to races
>> with the TrustZone firmware.  Until it is merged and the self-tests
>> are fixed, the driver definitely needs to be marked BROKEN.
>>
> 
> No, we currently don't ship TZ firmware that could cause such interactions.
> The only driver that currently suffers from such races is the NAND driver
> which races with the modem firmware and it too will use the BAM locking
> feature once it's upstream. However we do plan to support DRM using this IP
> and this is when it'll need to account for possible races. IOW: BAM locking
> is not strictly required to fix the QCE.

Thanks for the correction.

Will updated firmware alone cause races, or does the kernel need to
opt-in to firmware features that can cause them?  I want to make sure
that a firmware update will not cause the driver to start racing with
the secure world.

(Nit: DRM usually stands for "Direct Rendering Manager" in Linux.)

>> Also, what can the current driver do that cannot be done better using
>> software crypto?  I understand that you have future plans to add more
>> features to the driver, but those are not relevant to this discussion.
>>
> 
> We can offload crypto operations to the QCE saving CPU cycles but more
> importantly, the QCE provides HW based isolation which some vendors care
> about.

Would you mind explaining what you mean by "HW based isolation"?
While some crypto engines support keys that Linux doesn't have access
to, Linux only supports this on IBM mainframes.  Linux does support
using hardware-wrapped keys for inline storage encryption, but those
do not use this driver.
>> Finally, I very much appreciate the work you have done.  I don't
>> expect that the QCE driver will stay BROKEN forever.  This patch is
>> purely a reflection of the current state of the driver, the speed of
>> CPU-accelerated crypto, and the small message sizes used by the kernel.
>>
> 
> That may have been true when you sent the v1 but with a set of proposed fixes
> it'll no longer be the case.

I trust (and have always trusted) that you can fix the driver.
I apologize for not CCing you on the patch submission.

>> That said, is drivers/crypto really the right place for a restricted
>> content driver?  A driver that uses dmabufs might be a better
>> alternative, and would be easier to integrate with the Direct Rendering
>> Manager (DRM) and Video for Linux 2 (V4L2) subsystems.
>> --
> 
> These are future plans, yes. But right now we do have active users of this
> IP and now also a maintainer - yours truly - who stepped up and is actively
> working on this module. With the fixes applied, the driver will again pass
> crypto self-tests and should not be BROKEN.

With your patch, does the driver also pass stress tests, such as
multiple threads using it in parallel with varying algorithms and
message sizes?

If so, then I agree that the driver should no longer depend on
BROKEN, but I still question whether it is useful in its current form.
That's not specific to QCE, though.  I would say the same about many
other drivers.
-- 
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

[Eric Biggers]

On Wed, Jul 22, 2026 at 11:46:16AM -0400, Demi Marie Obenour wrote:
> With your patch, does the driver also pass stress tests, such as
> multiple threads using it in parallel with varying algorithms and
> message sizes?

As I've mentioned before, the self-tests (crypto/testmgr.c) don't issue
more than one request concurrently.  They are really designed for
testing the software implementations, not the hardware drivers.  None of
the hardware driver authors has ever caused enough about quality to make
any significant improvements to the tests.  Inevitably it's just push
the driver in, *maybe* run the existing incomplete tests once (for QCE
it's finally getting done just now), and job done I guess.

- Eric

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

[Eric Biggers]

On Wed, Jul 22, 2026 at 01:33:51AM -0700, Bartosz Golaszewski wrote:
> > Also, what can the current driver do that cannot be done better using
> > software crypto?  I understand that you have future plans to add more
> > features to the driver, but those are not relevant to this discussion.
> >
> 
> We can offload crypto operations to the QCE saving CPU cycles but more
> importantly, the QCE provides HW based isolation which some vendors care
> about.

Do you have any concrete proof of anyone using this with a specific
Linux kernel feature and actually getting a benefit from it?

Just for some additional context, I've been on the Android team for many
years and have worked with lots of companies shipping Android devices
with Qualcomm SoCs.  I also upstreamed the support for the
Qualcomm Inline Crypto Engine (ICE)
(https://lore.kernel.org/all/20200710072013.177481-6-ebiggers@kernel.org/
https://lore.kernel.org/linux-mmc/20210126001456.382989-9-ebiggers@kernel.org/),
which is what people actually use and isn't the same as QCE.

The only times the Linux QCE driver has ever come up is when someone
used it accidentally and it destroyed their performance (due to the
20-60x slower performance than the CPU) or caused a filesystem hang.

These issues get reported to me -- sometimes even from Qualcomm
themselves!  It's kind of annoying.

(Fortunately it's also quite rare, since the vast majority of people
just ignore QCE and don't make the mistake of using it in Linux.)

As far as I can tell, what actually works and what people actually use
in Linux on Qualcomm SoCs is:

- The Qualcomm Inline Crypto Engine (ICE) for storage encryption

- The ARMv8 Crypto Extensions everywhere else, e.g. dm-verity

> These are future plans, yes. But right now we do have active users of this
> IP

Just because it may be used by the Arm secure world doesn't mean it is
useful in Linux.

- Eric