Re: [PATCH] crypto: qce - Remove driver
Eric Biggers <[email protected]> Fri, 24 Jul 2026 07:14:14 -0700
| Newsgroups | org.kernel.vger.linux-crypto,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260724141414.GB1876@sol> |
On Fri, Jul 24, 2026 at 11:29:30AM +0200, Bartosz Golaszewski wrote: > It can't be used *accidentally*. It can still be used by in-kernel > users if you bump its priority via netlink. dm-verity, fscrypt, fsverity, and blk-crypto-fallback don't support this driver. The QCE driver itself has bugs that make it not work with dm-crypt and IPsec. That's all regardless of any theoretical tweaking via NETLINK_CRYPTO. That doesn't leave many upstream kernel features that could even *theoretically* be using the QCE driver if someone were to do the NETLINK_CRYPTO thing. Maybe SMB or kTLS? (But not with AES-GCM, as the QCE driver doesn't support AES-GCM. It would have to be AES-CCM.) However, over the years it's become extremely clear that virtually no one actually uses NETLINK_CRYPTO to tweak the algorithm priorities. It's part of the excessive "flexibility" of the crypto framework that is just not used in practice. Users actually just use the defaults. And with the defaults QCE is *never* used. So I think the NETLINK_CRYPTO thing is a red herring. There's just no credible upstream use case justifying this driver's retention. - Eric