Re: [PATCH v2 04/28] hw: mark all remaining virtio object types as secure

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Nov 13, 2026 at 11:16:15AM +0000, Alex Bennée wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > Alex, as the virtio-gpu* maintainer can you give your opinion
> > on the discussion below about virtio-gpu security tagging
> > vs our current security policy for "virtualization use case"
> > to ack/nack the proposal.
> 
> I'm inclined to agree with Marc-Andre here - the 3D GPU attack surface
> is large and for the in-QEMU handling we have a bunch of issues with GPU
> context handling between threads that make it tricky. Compounding that
> ruttabaga is not very well tested at all because its hard to enable
> without non-distro libs (for now).
> 
> Finally virtio-gpu is Odd Fixes so it's not getting the response times
> of other VirtIO stuff in terms of handling security issues.
> 
> We should encourage users to use vhost-user-gpu for 3D stuff because at
> least then the rendering pipeline and processing of guest controlled
> data is easier to sandbox.
> 
> So I'd say:
> 
>   - virtio-gpu for 2d - OK
>   - virtio-gpu for 3d via vhost - OK
>   - virtio-gpu for 3d in QEMU - Not OK

So, IIUC, in terms of what -device help reports, that would mean

Secure:

  name "vhost-user-gpu", bus virtio-bus
  name "vhost-user-gpu-pci", bus PCI
  name "virtio-gpu-device", bus virtio-bus
  name "virtio-gpu-pci", bus PCI, alias "virtio-gpu"

Not secure:

  name "virtio-gpu-gl-device", bus virtio-bus
  name "virtio-gpu-gl-pci", bus PCI, alias "virtio-gpu-gl"
  name "virtio-gpu-rutabaga-device", bus virtio-bus
  name "virtio-gpu-rutabaga-pci", bus PCI, alias "virtio-gpu-rutabaga"

?

>   
> Alex.
> 
> >
> > On Fri, Nov 06, 2026 at 05:33:31PM +0000, Daniel P. Berrangé wrote:
> >> On Fri, Nov 06, 2026 at 06:52:27PM +0400, Marc-André Lureau wrote:
> >> > Hi
> >> > 
> >> > On Fri, Nov 6, 2026 at 6:40 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >> > >
> >> > > On Fri, Nov 06, 2026 at 06:35:29PM +0400, Marc-André Lureau wrote:
> >> > > > Hi
> >> > > >
> >> > > > On Fri, Nov 6, 2026 at 3:53 PM Thomas Huth <thuth@redhat.com> wrote:
> >> > > > >
> >> > > > > On 29/10/2026 14.12, Daniel P. Berrangé wrote:
> >> > > > > > These are all intended for use in a virtualization scenario and must
> >> > > > > > provide a security boundary.
> >> > > > > >
> >> > > > > > Acked-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >> > > > > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> >> > > > > > ---
> >> > > > > Reviewed-by: Thomas Huth <thuth@redhat.com>
> >> > > > >
> >> > > >
> >> > > > I have a second thought about this, I'd like to exclude all
> >> > > > gpu-accelerated paths for now. virgl/mesa/rutabaga expose a very large
> >> > > > attack surface, so I'd like to drop them from the secure boundary
> >> > >
> >> > > Rather than repost, please see my response for patch 2:
> >> > >
> >> > >   https://lists.gnu.org/archive/html/qemu-devel/2026-11/msg01530.html
> >> > >
> >> > > TL;DR: we have already promised anything virtio related is in scope
> >> > > for security handling for a long time, as they are all unambiguously
> >> > > "virtualization use case".
> >> > >
> >> > 
> >> > the value of a secure policy enforcement is low if we know those
> >> > devices are unsecure and don't have the resources to make them secure.
> >> 
> >> It isn't a great situation to be in, but we're already there for any
> >> virtio devices based on our existing policies for bug handling and
> >> security triage. We can't promise we'll get fixes for all CVEs quickly,
> >> but we will at least assign CVEs so that users are aware when there
> >> are known problems.
> >> 
> >> This contrasts to other devices where problems will remain largely
> >> hidden for view, as we treat them as normal bugs and never call our
> >> security concerns when committing changes.
> >> 
> >> With regards,
> >> Daniel
> >> -- 
> >> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> >> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> >> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
> >> 
> >> 
> >
> > With regards,
> > Daniel
> 
> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|