Re: [PATCH] crypto: qce - Replace with stub driver

[Demi Marie Obenour <demiobenour@gmail.com>]

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

On 8/13/26 07:53, Bartosz Golaszewski wrote:
> On Wed, 12 Aug 2026 18:33:45 +0200, Demi Marie Obenour
> <demiobenour@gmail.com> said:
>> On 8/12/26 04:07, Bartosz Golaszewski wrote:
>>> On Wed, 12 Aug 2026 00:41:10 +0200, Eric Biggers <ebiggers@kernel.org> said:
>>>> On Tue, Aug 11, 2026 at 08:42:55AM -0500, Bartosz Golaszewski wrote:
>>>>
>>>>> No, the rationale has never been this. FWIW it can be that it's used for
>>>>> testing of the crypto module on a supported platform and that is already
>>>>> enough of a reason to keep it upstream.
>>>>>
>>>>> As I've said before: we don't just drop maintained drivers from linux.
>>>>
>>>> We definitely do if the drivers are not useful or appropriate for
>>>> inclusion in the kernel, though the policy varies by subsystem.  Even
>>>> just last month an entire filesystem got dropped despite someone wanting
>>>> to maintain it.
>>>>
>>>
>>> I suppose you're talking about EFS? A thing that can't even be tested on real
>>> hardware? This is a much more extreme case. Here you have several people
>>> representing the vendor saying they want to keep and maintain it. I'm fine
>>> having my own tree and sending PRs to Herbert if he agrees and you are of
>>> course entirely free to disregard any patches targetting it.
>>
>> Would you be okay with one of these options?
>>
>> 1. Make the stub driver as the default, with
>>    the real driver guarded by an off-by-default Kconfig option.
>>
>> 2. Keep the driver as is (with the power management issue fixed),
>>    but don't register any algorithm implementations with the crypto API.
>>
>> 3. Only register algorithm implementations with the crypto API if a
>>    non-default Kconfig option is selected.
>>
>> 4. Only register algorithm implementations with the crypto API if a
>>    non-default module parameter is selected.
>>
>> 5. Move the driver out of drivers/crypto, delete the algorithm
>>    registrations, and then add support for restricted media content
>>    decryption later.
>>
>> The last option would be my preferred one.
>>
> 
> I actually have a slightly different spin on the stub driver. I'd like to
> keep the driver future-proof and avoid all kinds of needless churn when we
> do get to the secure dma bufs and restricted media playback (and we will get
> there eventually :) ).
> 
> Can we make the QCE into an MFD driver with the core binding to the DT node
> and handling the interconnect bandwidth, while the part handling crypto
> algorithms becomes its cell and is moved into a separate module? This one can
> be disabled in defconfig by default and I don't even mind it being guarded with
> CONFIG_EXPERT. The core module would remain in arm64 defconfig.
> 
> With that: any future extensions providing support for more functionalities of
> this IP can simply be implemented as more MFD cells while we can also keep
> chipping away at the existing code and use it for testing the BAM pipe locking.

I'm not familiar with MFD drivers, but this sounds like the best
of both worlds.  The driver stays upstream, but anyone who doesn't
explicitly need it can ignore it.

>> Also, if Qualcomm has customers who use the QCE via the crypto API,
>> is Qualcomm aware of _why_ they made that choice?  From Eric's and
>> my perspective, that seems like a very strange decision, unless there
>> are factors that Eric and I are not aware of.
>>
> 
> SM8650 with the QCE is FIPS 140-2 certified and apparently this makes
> a difference. Don't ask me if that makes sense, I don't claim to understand
> the legal aspects of it.

That sounds like the kind of thing that would cause someone to use
a worse implementation of cryptographic algorithms 🙂.

For what it is worth, many common uses of kernel cryptography can't
use the QCE.  This notably applies to the CSPRNG (/dev/urandom etc),
storage encryption, and AF_ALG.  Therefore, I expect that anyone who
needs FIPS 140 compliance with Linux needs to ensure that the software
crypto is certified, as that's what actually gets used in most cases.
>> Finally, would you be willing to have a group call to discuss this
>> at some point?  That might be a more suitable venue for this kind of
>> discussion, and could potentially lead to a conclusion faster.  Also,
>> while at least I couldn't sign any NDAs, there might be information that
>> you could discuss there that you cannot post to a public mailing list.
> 
> Sure, I'm fine to have a call. If you think about coming to Linux Plumbers this
> year, I'll be there all week and it's a good place for such a discussion too.
> 
> FYI I've only been online for a couple days this week and I'm going offline
> again until the end of August with the exception of August 26th when I'll be
> able to chime in again. Any call would too have to happen in September at the
> earliest.
That's fine.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

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