.../devicetree/bindings/crypto/qcom-qce.yaml | 1 + .../devicetree/bindings/dma/qcom,bam-dma.yaml | 2 +- arch/arm64/boot/dts/qcom/shikra.dtsi | 35 ++++++++++++++++++++++ 3 files changed, 37 insertions(+), 1 deletion(-)
Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali.
Shikra bam dma supports 7 iommus so update dt-bindings accordingly.
The patchset depends on below. There's recursive dependency so referred
to base DT patch here.
- https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
Validations:
- make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check
- make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
- cryptobam and crypto driver probe
- kcapi test
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Kuldeep Singh (3):
dt-bindings: crypto: qcom-qce: Document the Shikra crypto engine
dt-bindings: bam-dma: Increase maxItems to seven for iommus
arm64: dts: qcom: shikra: Add qcrypto node support
.../devicetree/bindings/crypto/qcom-qce.yaml | 1 +
.../devicetree/bindings/dma/qcom,bam-dma.yaml | 2 +-
arch/arm64/boot/dts/qcom/shikra.dtsi | 35 ++++++++++++++++++++++
3 files changed, 37 insertions(+), 1 deletion(-)
---
base-commit: 33c8e3305b65a2e757e68b10af521ad54ea051a6
change-id: 20260514-shikra_qcrypto-f61f4d363e6e
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
On 15-05-2026 00:53, Kuldeep Singh wrote: > Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali. > Shikra bam dma supports 7 iommus so update dt-bindings accordingly. > > The patchset depends on below. There's recursive dependency so referred > to base DT patch here. > - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/ > > Validations: > - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check > - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml > - cryptobam and crypto driver probe > - kcapi test > > Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Kind reminder, rng/ice/qcrypto patchsets are sent together sometime back in single series and please follow here[1] for discussions. Please consider this series as inactive from merger point of view. Can still use for already engaged discussion. [1] https://lore.kernel.org/all/20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com/ -- Regards Kuldeep
On Fri, May 15, 2026 at 12:53:35AM +0530, Kuldeep Singh wrote: > Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali. > Shikra bam dma supports 7 iommus so update dt-bindings accordingly. > > The patchset depends on below. There's recursive dependency so referred > to base DT patch here. > - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/ > > Validations: > - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check > - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml > - cryptobam and crypto driver probe > - kcapi test > > Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> What specific kernel features would this be useful for, and what specific performance improvements are you seeing with those features? - Eric
On 15-05-2026 01:17, Eric Biggers wrote: > On Fri, May 15, 2026 at 12:53:35AM +0530, Kuldeep Singh wrote: >> Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali. >> Shikra bam dma supports 7 iommus so update dt-bindings accordingly. >> >> The patchset depends on below. There's recursive dependency so referred >> to base DT patch here. >> - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/ >> >> Validations: >> - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check >> - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml >> - cryptobam and crypto driver probe >> - kcapi test >> >> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> > > What specific kernel features would this be useful for, and what > specific performance improvements are you seeing with those features? I hope you mean 7 iommu entries. Please note, shikra is an old platform and differs with latest platforms like kaanapali in terms of iommus#. Kaanapali is optimised(in terms of iommus#) as same pipe index/sid i.e 4/5 can be used for general purpose or for any other usecase like DRM/HDCP etc. Whereas for shikra, there's dedicated iommu entry for each usecase and same pipe index/sid cannot be used for other usecases. The performance will be be effectively similar. -- Regards Kuldeep
On Thu, May 21, 2026 at 12:21:41PM +0530, Kuldeep Singh wrote:
> On 15-05-2026 01:17, Eric Biggers wrote:
> > On Fri, May 15, 2026 at 12:53:35AM +0530, Kuldeep Singh wrote:
> >> Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali.
> >> Shikra bam dma supports 7 iommus so update dt-bindings accordingly.
> >>
> >> The patchset depends on below. There's recursive dependency so referred
> >> to base DT patch here.
> >> - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/
> >>
> >> Validations:
> >> - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check
> >> - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
> >> - cryptobam and crypto driver probe
> >> - kcapi test
> >>
> >> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
> >
> > What specific kernel features would this be useful for, and what
> > specific performance improvements are you seeing with those features?
>
> I hope you mean 7 iommu entries.
>
> Please note, shikra is an old platform and differs with latest platforms
> like kaanapali in terms of iommus#.
> Kaanapali is optimised(in terms of iommus#) as same pipe index/sid i.e
> 4/5 can be used for general purpose or for any other usecase like
> DRM/HDCP etc.
> Whereas for shikra, there's dedicated iommu entry for each usecase and
> same pipe index/sid cannot be used for other usecases.
>
> The performance will be be effectively similar.
It sounds like you don't actually have an answer to my questions, then.
Performance tests (e.g.
https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly
shown that this driver is an order of magnitude slower than the CPU.
This driver has historically been quite harmful. People were using it
accidentally and encountering very bad performance, as well as bugs such
as crashes and filesystem hangs. We fixed that by lowering its
cra_priority. But for the same reason, even when enabled on a platform,
it's not actually used. Linux would be better without this driver.
We seem to be seeing the usual drivers/crypto/ pattern here: this crypto
offload driver is being pushed by the hardware manufacturer, with no
awareness of the fact that it's actually useless in Linux.
I've had enough of this. Please consider this series:
Nacked-by: Eric Biggers <ebiggers@kernel.org>
FWIW: the approaches that are actually used and work well in Linux are
ICE and the CPU-accelerated crypto.
- Eric
On Thu, May 21, 2026 at 09:49:12PM -0500, Eric Biggers wrote: > On Thu, May 21, 2026 at 12:21:41PM +0530, Kuldeep Singh wrote: > > On 15-05-2026 01:17, Eric Biggers wrote: > > > On Fri, May 15, 2026 at 12:53:35AM +0530, Kuldeep Singh wrote: > > >> Add qcrypto and cryptobam DT nodes for enabling qcrypto on kaanapali. > > >> Shikra bam dma supports 7 iommus so update dt-bindings accordingly. > > >> > > >> The patchset depends on below. There's recursive dependency so referred > > >> to base DT patch here. > > >> - https://lore.kernel.org/all/20260512-shikra-dt-v1-0-716438330dd0@oss.qualcomm.com/ > > >> > > >> Validations: > > >> - make ARCH=arm64 DT_CHECKER_FLAGS=-m DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml dt_binding_check > > >> - make ARCH=arm64 qcom/shikra-cqs-evk.dtb CHECK_DTBS=1 DT_SCHEMA_FILES=Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml > > >> - cryptobam and crypto driver probe > > >> - kcapi test > > >> > > >> Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> > > > > > > What specific kernel features would this be useful for, and what > > > specific performance improvements are you seeing with those features? > > > > I hope you mean 7 iommu entries. > > > > Please note, shikra is an old platform and differs with latest platforms > > like kaanapali in terms of iommus#. > > Kaanapali is optimised(in terms of iommus#) as same pipe index/sid i.e > > 4/5 can be used for general purpose or for any other usecase like > > DRM/HDCP etc. > > Whereas for shikra, there's dedicated iommu entry for each usecase and > > same pipe index/sid cannot be used for other usecases. > > > > The performance will be be effectively similar. > > It sounds like you don't actually have an answer to my questions, then. > > Performance tests (e.g. > https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly > shown that this driver is an order of magnitude slower than the CPU. Are other harware crypto drivers faster or slower than the CPU implementation? What about the CAAM (sorry, it's just the driver that I worked with few years ago). Or Xilinx? My guess would be that for the most of the modern ARM64 hardware the NEON implementation is faster than the "hw IP" one. My assumtion has always been that we support crypto IP for the sake of security (i.e. making sure that the key can't be found in the cleartext in memory dumps or that it's impossible to tamper with the hash values before singing/verification). From this point of view, using priorities is expected and logical: most of the users will need a quickest implementation. Some users will need to use protected keys or other hw-only features. Note, I'm not commenting on the driver being buggy. If the issues are not fixed in a timely manner, it should be marked with 'depends on BROKEN' and further removed if the issues contine to be non-fixed. > This driver has historically been quite harmful. People were using it > accidentally and encountering very bad performance, as well as bugs such > as crashes and filesystem hangs. We fixed that by lowering its > cra_priority. But for the same reason, even when enabled on a platform, > it's not actually used. Linux would be better without this driver. > > We seem to be seeing the usual drivers/crypto/ pattern here: this crypto > offload driver is being pushed by the hardware manufacturer, with no > awareness of the fact that it's actually useless in Linux. > > I've had enough of this. Please consider this series: > > Nacked-by: Eric Biggers <ebiggers@kernel.org> > > FWIW: the approaches that are actually used and work well in Linux are > ICE and the CPU-accelerated crypto. > > - Eric -- With best wishes Dmitry
On Mon, May 25, 2026 at 01:07:49PM +0300, Dmitry Baryshkov wrote:
> Are other harware crypto drivers faster or slower than the CPU
> implementation? What about the CAAM (sorry, it's just the driver that I
> worked with few years ago). Or Xilinx? My guess would be that for the
> most of the modern ARM64 hardware the NEON implementation is faster than
> the "hw IP" one.
Yes, QCE is hardly unique here. It's just the one we're discussing now.
> My assumtion has always been that we support crypto IP
> for the sake of security (i.e. making sure that the key can't be found
> in the cleartext in memory dumps or that it's impossible to tamper with
> the hash values before singing/verification). From this point of view,
> using priorities is expected and logical: most of the users will need a
> quickest implementation. Some users will need to use protected keys or
> other hw-only features.
>
> Note, I'm not commenting on the driver being buggy. If the issues are
> not fixed in a timely manner, it should be marked with 'depends on
> BROKEN' and further removed if the issues contine to be non-fixed.
Only a few drivers support protected keys ("paes", "phmac"); QCE is
*not* one of them. There are also no explicit users of protected keys
in the kernel, so even if supported by the driver, it's almost never
used in practice in Linux. The only way this feature could potentially
be used in Linux is if one of these drivers is present *and* userspace
explicitly chooses to use it with one of the few kernel features that
might implicitly support it, e.g. dm-crypt. AFAIK that's extremely
rare, and at least in Linux it's really just a checkbox feature.
(HW-wrapped inline crypto keys do get used, but those don't use the
crypto API or these drivers at all.)
As for making it "impossible to tamper with the hash values before
signing/verification", these drivers don't provide anything there.
- Eric
> It sounds like you don't actually have an answer to my questions, then. > > Performance tests (e.g. > https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly > shown that this driver is an order of magnitude slower than the CPU. > > This driver has historically been quite harmful. People were using it > accidentally and encountering very bad performance, as well as bugs such > as crashes and filesystem hangs. We fixed that by lowering its > cra_priority. But for the same reason, even when enabled on a platform, > it's not actually used. Linux would be better without this driver. > +Bartosz, Gaurav, Neeraj Hi Eric, GPCE is relevant in terms of providing hardware security. There are multiple usecases coming up for example to handle DRM/secure buffer usecases to improve overall throughput for secure content. Regarding performance, it's currently slower compared to arm CE but provides an edge by giving hardware security which is considered more secure. Btw, there's been performance improvement with new targets and we are expecting to achieve far more better performance with new SoCs family. Pakala: GPCE - 550MBps, ARMv8 - 8GBps Kaanapali: GPCE - 3GBps, ARMv8 - 10GBps Please note, there's almost 5x improvement in kaanapali compared to pakala. Though overall is still slower compared to arm but as mentioned, expecting better performance with hardware improvements as we progress. Also, currently qce driver exhibit stability issues and that's what we are putting effort in stabilizing the software on immediate basis. There's parallel effort ongoing by Bartosz to introduce baseline for secure buffer usecases. https://lore.kernel.org/lkml/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com/ There's active development ongoing and i believe lowering cra_priority for qce is fine as of now and can scale values once qce becomes performance efficient. Please share your thoughts. Thanks! -- Regards Kuldeep
On Mon, May 25, 2026 at 11:10:10AM +0530, Kuldeep Singh wrote:
> > It sounds like you don't actually have an answer to my questions, then.
> >
> > Performance tests (e.g.
> > https://lore.kernel.org/r/20250615031807.GA81869@sol/) have clearly
> > shown that this driver is an order of magnitude slower than the CPU.
> >
> > This driver has historically been quite harmful. People were using it
> > accidentally and encountering very bad performance, as well as bugs such
> > as crashes and filesystem hangs. We fixed that by lowering its
> > cra_priority. But for the same reason, even when enabled on a platform,
> > it's not actually used. Linux would be better without this driver.
> >
>
> +Bartosz, Gaurav, Neeraj
>
> Hi Eric,
>
> GPCE is relevant in terms of providing hardware security.
> There are multiple usecases coming up for example to handle DRM/secure
> buffer usecases to improve overall throughput for secure content.
>
> Regarding performance, it's currently slower compared to arm CE but
> provides an edge by giving hardware security which is considered more
> secure.
>
> Btw, there's been performance improvement with new targets and we are
> expecting to achieve far more better performance with new SoCs family.
> Pakala: GPCE - 550MBps, ARMv8 - 8GBps
> Kaanapali: GPCE - 3GBps, ARMv8 - 10GBps
>
> Please note, there's almost 5x improvement in kaanapali compared to
> pakala. Though overall is still slower compared to arm but as mentioned,
> expecting better performance with hardware improvements as we progress.
>
> Also, currently qce driver exhibit stability issues and that's what we
> are putting effort in stabilizing the software on immediate basis.
>
> There's parallel effort ongoing by Bartosz to introduce baseline for
> secure buffer usecases.
> https://lore.kernel.org/lkml/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com/
> There's active development ongoing and i believe lowering cra_priority
> for qce is fine as of now and can scale values once qce becomes
> performance efficient.
>
> Please share your thoughts. Thanks!
ARMv8 Crypto Extensions are "hardware" as well, just in the CPU. They
provide constant-time execution, for example.
Granted, they don't protect from power analysis and electromagnetic
emanation attacks. Does QCE actually provide those protections, though?
Either way, it doesn't really matter in this case. There are multiple
aspects to security, and before even considering these advanced
protections, the basics of security need to be absolutely solid. That
is, the driver needs to always compute the crypto algorithms correctly,
and it needs to be completely robust when fuzzed by unprivileged
userspace (because it can accessed in that way).
Yet, this driver "exhibits stability issues", fails the self-tests, and
doesn't even have exclusive access to the hardware! These are all
security bugs. That very much defeats the claimed point. (Plus, due to
the performance issues no one wants to use it in Linux anyway.)
As for "decrypting into secure buffers": if added that would be a new
feature, separate from the driver's current features. It's not even
supported by the crypto API. So regardless of whether this would be a
useful feature or not (it's unclear it would be), using it as an
argument that the current features of the driver are useful is nonsense.
As for performance getting higher over time, it's still irrelevant when
it's still much slower than the CPU, especially in practical conditions.
Yet, somehow this driver is documented as an "accelerator":
config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
The CPU is just much a better approach performance-wise. It has no
overhead in setting up DMA, waking/notifying the hardware, and context
switching. The CPU has a lot of room to improve too, via further
optimizations to hardware and the ISA, and in some cases software
optimizations such as interleaving. We've already seen this play out on
x86_64, where Vector AES boosted the AES throughput by a further 2-4x
from its already-super-fast performance.
- Eric
>> +Bartosz, Gaurav, Neeraj >> >> Hi Eric, >> >> GPCE is relevant in terms of providing hardware security. >> There are multiple usecases coming up for example to handle DRM/secure >> buffer usecases to improve overall throughput for secure content. >> >> Regarding performance, it's currently slower compared to arm CE but >> provides an edge by giving hardware security which is considered more >> secure. >> >> Btw, there's been performance improvement with new targets and we are >> expecting to achieve far more better performance with new SoCs family. >> Pakala: GPCE - 550MBps, ARMv8 - 8GBps >> Kaanapali: GPCE - 3GBps, ARMv8 - 10GBps >> >> Please note, there's almost 5x improvement in kaanapali compared to >> pakala. Though overall is still slower compared to arm but as mentioned, >> expecting better performance with hardware improvements as we progress. >> >> Also, currently qce driver exhibit stability issues and that's what we >> are putting effort in stabilizing the software on immediate basis. >> >> There's parallel effort ongoing by Bartosz to introduce baseline for >> secure buffer usecases. >> https://lore.kernel.org/lkml/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com/ >> There's active development ongoing and i believe lowering cra_priority >> for qce is fine as of now and can scale values once qce becomes >> performance efficient. >> >> Please share your thoughts. Thanks! > > ARMv8 Crypto Extensions are "hardware" as well, just in the CPU. They > provide constant-time execution, for example. > > Granted, they don't protect from power analysis and electromagnetic > emanation attacks. Does QCE actually provide those protections, though? QCE doesn't provide these protections currently. What i wanted to highlight was there are certain security usecases which are possible via dedicated crypto engine only and not via arm cpu. > Either way, it doesn't really matter in this case. There are multiple > aspects to security, and before even considering these advanced > protections, the basics of security need to be absolutely solid. That > is, the driver needs to always compute the crypto algorithms correctly, > and it needs to be completely robust when fuzzed by unprivileged > userspace (because it can accessed in that way). > Yet, this driver "exhibits stability issues", fails the self-tests, and > doesn't even have exclusive access to the hardware! These are all > security bugs. That very much defeats the claimed point. (Plus, due to > the performance issues no one wants to use it in Linux anyway.) Sure, we are analyzing self-tests failures and are committed to fix any hung/stability issue in any aspect but i do feel it should not be a blocker to add new soc id support. Also, could you please elaborate more on "exclusive access to hardware"? Do you mean the hardware can be accessed by multiple execution environment like TEE and Linux? -- Regards Kuldeep
On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> said: >>> +Bartosz, Gaurav, Neeraj >>> >>> Hi Eric, >>> >>> GPCE is relevant in terms of providing hardware security. >>> There are multiple usecases coming up for example to handle DRM/secure >>> buffer usecases to improve overall throughput for secure content. >>> >>> Regarding performance, it's currently slower compared to arm CE but >>> provides an edge by giving hardware security which is considered more >>> secure. >>> >>> Btw, there's been performance improvement with new targets and we are >>> expecting to achieve far more better performance with new SoCs family. >>> Pakala: GPCE - 550MBps, ARMv8 - 8GBps >>> Kaanapali: GPCE - 3GBps, ARMv8 - 10GBps >>> >>> Please note, there's almost 5x improvement in kaanapali compared to >>> pakala. Though overall is still slower compared to arm but as mentioned, >>> expecting better performance with hardware improvements as we progress. >>> >>> Also, currently qce driver exhibit stability issues and that's what we >>> are putting effort in stabilizing the software on immediate basis. >>> >>> There's parallel effort ongoing by Bartosz to introduce baseline for >>> secure buffer usecases. >>> https://lore.kernel.org/lkml/20260522-qcom-qce-cmd-descr-v18-0-99103926bafc@oss.qualcomm.com/ >>> There's active development ongoing and i believe lowering cra_priority >>> for qce is fine as of now and can scale values once qce becomes >>> performance efficient. >>> >>> Please share your thoughts. Thanks! >> >> ARMv8 Crypto Extensions are "hardware" as well, just in the CPU. They >> provide constant-time execution, for example. >> >> Granted, they don't protect from power analysis and electromagnetic >> emanation attacks. Does QCE actually provide those protections, though? > > QCE doesn't provide these protections currently. > What i wanted to highlight was there are certain security usecases which > are possible via dedicated crypto engine only and not via arm cpu. >> Either way, it doesn't really matter in this case. There are multiple >> aspects to security, and before even considering these advanced >> protections, the basics of security need to be absolutely solid. That >> is, the driver needs to always compute the crypto algorithms correctly, >> and it needs to be completely robust when fuzzed by unprivileged >> userspace (because it can accessed in that way). > > Yet, this driver "exhibits stability issues", fails the self-tests, and >> doesn't even have exclusive access to the hardware! These are all >> security bugs. That very much defeats the claimed point. (Plus, due to >> the performance issues no one wants to use it in Linux anyway.) > > Sure, we are analyzing self-tests failures and are committed to fix any > hung/stability issue in any aspect but i do feel it should not be a > blocker to add new soc id support. > > Also, could you please elaborate more on "exclusive access to hardware"? > Do you mean the hardware can be accessed by multiple execution > environment like TEE and Linux? > -- > Regards > Kuldeep > > Eric: FYI I do plan - and have been allowed to by Qualcomm - to work on this driver further to refactor and improve it. However, the BAM locking series[1] needs to be queued first as it significantly changes the way the driver works. Any help with reviewing and getting these patches merged is appreciated. I don't want to start sending more patches before the 14 commit series gets queued first. Vinod: the series has been reviewed and tested. The NAND team at qualcomm is telling me they're using it internally already to fix a race between the modem firmware and linux. Can we get it queued for v7.2 please? This will make further refactoring easier. I know about the self-tests etc., I will address them next. Bart [1] https://lore.kernel.org/all/20260526-qcom-qce-cmd-descr-v19-0-08472fdcbf4a@oss.qualcomm.com/
On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote: > On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh > <kuldeep.singh@oss.qualcomm.com> said: > >>> +Bartosz, Gaurav, Neeraj > > I know about the self-tests etc., I will address them next. My 2c, the self-tests would be more important, as they are fixes. Doing the crypto in a wrong way is a bad idea... -- With best wishes Dmitry
On Thu, 28 May 2026 15:50:10 +0200, Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> said: > On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote: >> On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh >> <kuldeep.singh@oss.qualcomm.com> said: >> >>> +Bartosz, Gaurav, Neeraj >> >> I know about the self-tests etc., I will address them next. > > My 2c, the self-tests would be more important, as they are fixes. Doing > the crypto in a wrong way is a bad idea... > Then let that be "in parallel". :) Bart
On Thu, May 28, 2026 at 11:13:47AM -0400, Bartosz Golaszewski wrote: > On Thu, 28 May 2026 15:50:10 +0200, Dmitry Baryshkov > <dmitry.baryshkov@oss.qualcomm.com> said: > > On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote: > >> On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh > >> <kuldeep.singh@oss.qualcomm.com> said: > >> >>> +Bartosz, Gaurav, Neeraj > >> > >> I know about the self-tests etc., I will address them next. > > > > My 2c, the self-tests would be more important, as they are fixes. Doing > > the crypto in a wrong way is a bad idea... > > > > Then let that be "in parallel". :) The race conditions between Linux and other environments (modem, TEE, etc) are of course about correctness as well, even though the self-tests don't expose race condition bugs. The self-tests have always just done a few serialized tests. That's sufficient for CPU-based code, but not for offload drivers, which need to be stress-tested to find the concurrency bugs that occur during actual use. Is there a plan to improve the tests to do stress testing as well? It's kind of odd that they don't do that yet. But it makes sense: the CPU-based code doesn't need it, while the offload driver authors have never cared enough about correctness and test coverage to add it. I still don't really see a path forward here, given the track record and poor performance numbers. This approach just doesn't work. - Eric
On Thu, May 28, 2026 at 7:52 PM Eric Biggers <ebiggers@kernel.org> wrote: > > On Thu, May 28, 2026 at 11:13:47AM -0400, Bartosz Golaszewski wrote: > > On Thu, 28 May 2026 15:50:10 +0200, Dmitry Baryshkov > > <dmitry.baryshkov@oss.qualcomm.com> said: > > > On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote: > > >> On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh > > >> <kuldeep.singh@oss.qualcomm.com> said: > > >> >>> +Bartosz, Gaurav, Neeraj > > >> > > >> I know about the self-tests etc., I will address them next. > > > > > > My 2c, the self-tests would be more important, as they are fixes. Doing > > > the crypto in a wrong way is a bad idea... > > > > > > > Then let that be "in parallel". :) > > The race conditions between Linux and other environments (modem, TEE, > etc) are of course about correctness as well, even though the self-tests > don't expose race condition bugs. The self-tests have always just done > a few serialized tests. That's sufficient for CPU-based code, but not > for offload drivers, which need to be stress-tested to find the > concurrency bugs that occur during actual use. > > Is there a plan to improve the tests to do stress testing as well? > I'm not sure if we can easily implement linux-only tests using multiple execution environments. I will look into it and come back with an answer. > It's kind of odd that they don't do that yet. But it makes sense: the > CPU-based code doesn't need it, while the offload driver authors have > never cared enough about correctness and test coverage to add it. > > I still don't really see a path forward here, given the track record and > poor performance numbers. This approach just doesn't work. > Sorry but I'm not sure what your point is. What this series does is: it documents the compatible for the crypto engine that very much *does exist* on the SoC and describes how it's wired up as a real HW component in devicetree. Whatever the state of the driver is, it's not grounds for NAKing HW description. The IP *is* there, we're allowed to describe it in DTS. Qualcomm wants to use this IP and I will keep on improving it. I think that - given the BAM locking series is at v19 now and has been initially posted in 2023 - I've a proven track record of not abandoning it. :) I'm away next week but will look into self-tests the week after. This series - once fixed - should go upstream independently. Bart
> On Thu, May 28, 2026 at 7:52 PM Eric Biggers <ebiggers@kernel.org> wrote: >> >> On Thu, May 28, 2026 at 11:13:47AM -0400, Bartosz Golaszewski wrote: >>> On Thu, 28 May 2026 15:50:10 +0200, Dmitry Baryshkov >>> <dmitry.baryshkov@oss.qualcomm.com> said: >>>> On Thu, May 28, 2026 at 09:13:23AM -0400, Bartosz Golaszewski wrote: >>>>> On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh >>>>> <kuldeep.singh@oss.qualcomm.com> said: >>>>>>>> +Bartosz, Gaurav, Neeraj >>>>> >>>>> I know about the self-tests etc., I will address them next. All, kindly help in reviewing selftests fixes for QCE. https://lore.kernel.org/linux-arm-msm/20260610-qce_selftest_fix-v1-0-1b0504783a46@oss.qualcomm.com/ -- Regards Kuldeep
On Mon, May 25, 2026 at 09:28:43AM -0500, Eric Biggers wrote:
> ARMv8 Crypto Extensions are "hardware" as well, just in the CPU. They
> provide constant-time execution, for example.
>
> Granted, they don't protect from power analysis and electromagnetic
> emanation attacks. Does QCE actually provide those protections, though?
>
> Either way, it doesn't really matter in this case. There are multiple
> aspects to security, and before even considering these advanced
> protections, the basics of security need to be absolutely solid. That
> is, the driver needs to always compute the crypto algorithms correctly,
> and it needs to be completely robust when fuzzed by unprivileged
> userspace (because it can accessed in that way).
Looks like these protections are not even present either. From
https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp5077.pdf :
> The Qualcomm Crypto Engine Core does not support any non-invasive
> security techniques. Therefore, this section is not applicable.
[...]
> The Qualcomm Crypto Engine Core does not implement security
> mechanisms to mitigate other attacks.
- Eric
© 2016 - 2026 Red Hat, Inc.