Re: [PATCH 0/3] Add support for qcrypto on shikra

[Bartosz Golaszewski]

On Thu, 28 May 2026 13:54:51 +0200, Kuldeep Singh
<kuldeep.singh@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx/
>>> 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@xxxxxxxxxxxxxxxx/