> -----Original Message----- > From: Michael S. Tsirkin <[email protected]> > Sent: Thursday, August 20, 2026 5:56 AM > To: Alex Bennée <[email protected]> > Cc: [email protected]; Philippe Mathieu-Daudé <[email protected]>; > Pierrick Bouvier <[email protected]>; Peter Maydell > <[email protected]>; [email protected]; Gonglei (Arei) > <[email protected]>; zhenwei pi <[email protected]>; Stefano > Garzarella <[email protected]>; Laurent Vivier <[email protected]>; Amit > Shah <[email protected]>; Marc-André Lureau > <[email protected]>; Paolo Bonzini <[email protected]>; > John Snow <[email protected]>; Kevin Wolf <[email protected]>; Hanna > Reitz <[email protected]>; [email protected]; [email protected] > Subject: Re: [PATCH 6/6] docs: deprecate virtio-crypto > > On Wed, Aug 19, 2026 at 10:22:06AM +0100, Alex Bennée wrote: > > We have outstanding guest exploitable bugs in the code which is fairly > > complex and needs some serious love to clean it up. As off-CPU > > cryptography acceleration seems to be waning in popularity lets just > > deprecate the sub-system with a view to removing it in a couple of > > cycles. > > > > Link: https://gitlab.com/qemu-project/qemu/-/work_items/3625 > > Signed-off-by: Alex Bennée <[email protected]> > > Cc: Gonglei <[email protected]> > > Let's see what Gonglei thinks. > Hi Alex, Michael,
Thanks for the patch. As the virtio-crypto maintainer let me first respond to Michael's three points, then give my formal position on the deprecation - including a scope clarification that I think the community should be aware of. I ACK deprecating virtio-crypto since 11.2, but I want to be explicit that this is effectively a *subsystem-level* deprecation, not just a single device: - In QEMU today, virtio-crypto is the *only* frontend device that consumes the cryptodev backends (cryptodev-builtin, cryptodev-vhost-user, cryptodev-lkcf). There is no standalone vhost-user-crypto device - the vhost-user crypto path is driven through virtio-crypto as well (virtio_crypto_vhost_status -> cryptodev_vhost_start). So removing virtio-crypto orphans the entire backend subsystem, backends/cryptodev-vhost.c, and the vhost-user crypto session protocol support in hw/virtio/vhost-user.c. - I'd therefore like the deprecation to cover that scope explicitly and to plan the cleanup of the backends together with the device, so we don't leave dead, unmaintained objects behind. This includes deciding the fate of the recently added cryptodev-lkcf backend. The basis and commitments behind my ACK: - The emulation has had a string of guest-exploitable issues (CVE-2023-3180, CVE-2024-3446, CVE-2024-8612, CVE-2025-14876) and has been unmigratable since day one (.unmigratable = 1), which indeed undercuts its use in serious virtualization. Maintainer bandwidth is limited. - I will keep landing fixes for the known guest-exploitable bugs during the deprecation window (several are already in flight, e.g. the asym/akcipher size hardening addressing the CVE-2025-14876 class of issues), so the code stays safe while it is being removed. Realistic migration path for any existing users (there is no virtio replacement, so it's honest to say so): - in-guest CPU crypto (AES-NI/VAES etc.) for the common case, and - host-side direct assignment of crypto accelerators via VFIO (e.g. Intel QAT, ConnectX) for the workloads that genuinely need offload, which is also the better-performing path (avoids vmexit overhead, as Mohamed noted). Finally, please let's use the deprecation window to surface any real users before scheduling the actual removal. Proposed replacement text for docs/about/deprecated.rst: The `virtio-crypto` device emulation is quite complex code with a number of known flaws. It has never been migratable, so it is unlikely to be used in any serious virtualization setting. Modern ISAs provide on-CPU cryptography instructions (e.g. AES-NI/VAES, armv8 crypto extensions), and the Linux kernel deprecated AF_ALG and dropped its off-CPU accelerator support in Linux 7.2, removing the primary userspace path for off-CPU crypto acceleration. The time for this sort of off-load has passed. > > --- > > docs/about/deprecated.rst | 14 ++++++++++++++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst > > index 0c656a968fc..3c22981fc8a 100644 > > --- a/docs/about/deprecated.rst > > +++ b/docs/about/deprecated.rst > > @@ -276,6 +276,20 @@ future release. Where no 'dh-params.pem' file is > > provided, the DH parameters will be automatically negotiated in > > accordance with RFC7919. > > > > +Devices > > +------- > > + > > +``virtio-crypto`` (since 11.2) > > +'''''''''''''''''''''''''''''' > > + > > +The ``virtio-crypto`` device emulation is quite complex code with a > > +number of known flaws. It has never been migratable so is unlikely to > > +be used in any serious virtualization setting. With most modern > > +systems supporting on-CPU cryptography acceleration via their ISAs > > +sets > > ISA sets? > Fair catch, that phrasing was sloppy. The point is that modern ISAs expose on-CPU cryptography instructions (x86 AES-NI/VAES, armv8 crypto extensions, RISC-V scalar crypto, s390x KIMD/KM, ...). For the common case there is no longer a performance win in bouncing the request to an off-CPU engine. > > the need for off-CPU acceleration is also reduced. Add to > > +that the kernel has recently removed the ability to use off-CPU > > +acceleration > > did it really? I thought it's just for af_alg? > You are right. To be precise: the virtio-crypto *driver* (CONFIG_CRYPTO_DEV_VIRTIO) is still present in the Linux kernel and is still being maintained (it received fixes for CVE-2024-26753 and, most recently, CVE-2026-23229). What the kernel actually deprecated is AF_ALG, whose off-CPU accelerator support was dropped for Linux 7.2 (Eric Biggers), and AF_ALG is the primary userspace path a guest would use for virtio-crypto (e.g. OpenSSL's afalg engine). The docs should say exactly that, not "the kernel removed the ability to use off-CPU acceleration" in general. > and putting "recently" into cde will not age well. > Agreed. "recently" is time-dependent and has no place in deprecated.rst. I'd reference the concrete kernel change instead (AF_ALG deprecation / offload removal in Linux 7.2), which is version-stable. Regards, -Gonglei
