Re: [PATCH v2 4/4] vga/cirrus: deprecate, don't build by default

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

On Wed, Jun 05, 2024 at 09:32:01AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > > Upstream QEMU's scope is to emulate pretty much arbitrary hardware that
> > > may have existed at any point in time. Emulating Cirrus is very much
> > > in scope upstream, and even if there are other better VGA devices, that
> > > doesn't make emulation of Cirrus redundant.
> > > 
> > > Downstream is a different matter - if a downstream vendor wants to be
> > > opinionated and limit the scope of devices they ship to customers, it
> > > is totally valid to cull Cirrus.
> > 
> > Few years ago I suggested qemu_security_policy_taint() "which allows
> > unsafe (read "not very maintained") code to 'taint' QEMU security
> > policy." (Gerd FYI):
> > https://lore.kernel.org/qemu-devel/20210908232024.2399215-1-philmd@redhat.com/
> > 
> > Upstream we could add a boolean in DeviceClass about device security
> > status / maintenance (or enum or bitfield); then downstreams could
> > use it to be sure unsafe devices aren't linked in.
> 
> Yes, I think it makes sense to maintain that information upstream.  It
> is useful information to have.  Even if upstream isn't going to enforce
> something qemu could print useful hints.
> 
> So, the question is whenever we want go for a simple bool, or go for a
> bitfield giving more detailed information.  Bits I think could be
> useful:
> 
>   (1) OBJECT_STATUS_DEPRECATED
>       Stuff we actually want remove.  Very few cases, maybe usb-hub.
> 
>   (2) OBJECT_STATUS_UNSAFE
>       "not very maintained".  Probably need a better name for this.

If it reflects maintainer status, then we're obvioulsy overlapping
with the MAINTAINERS file info, but "UNSAFE" suggests something
different....

So what I think would be valuable is marking whether a device is
considered to provide a guest security boundary.  This would in turn
indicate whether we would treat flaws in its impl as being worthy of
triaging as CVEs, or merely be normal bugs.

We already document in security.rst that we consider virtualization
use cases only to provide a security boundary, but on every bug report
we have to decide whether the device in question is considered relevant
to a "virtualization"  use case.

This was a known limitation, because we had no metadata to track
which devices were considered "secure". It was always expected that
long term we should be tagging devices/machines/accelerators/etc
with their security status.

It would be nice from an end user POV to be able to have a way to tell
QEMU to enforce that a given VM provides a guest security boundary, and
get a hard error at startup, or hot-plug if any device cannot satisfy
that requirement.

>   (3) OBJECT_STATUS_OUTDATED
>       Old device where newer / better alternatives exist.

I think (3) is pretty hard to define, as "better" is very much a
use case specific decision. You could say that everything, for
which a virtio device exists, has a "better" alternative. That's
only true if running a modern OS though. If running a vintage
OS, the "outdated" thing is liley "better".

> Looking at the USB host adapters I'd attach 2+3 to ohci and 3 to uhci
> and ehci.  In general there is a lot of overlap for (2) + (3) though.
> 
> We might also have recommendation bits such as:
> 
>   (4) OBJECT_STATUS_VIRTUALIZATON
>       Devices recommended for virtualization use cases
>       (all virtio, xhci, ...).

Even that has the same problem as (3) - the recommended devices
differ depending on what OS you're intending to use.

This problem is pretty much why libosinfo exists to provide more
guided hardware recommendations tailored to OS.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|