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-phi...@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 :|
