Re: [Qemu-devel] [PATCH 3/3] cirrus: mark as deprecated

[Daniel P . Berrangé]

On Fri, Oct 26, 2018 at 10:42:08AM +0100, Daniel P. Berrangé wrote:
> On Fri, Oct 26, 2018 at 12:33:55PM +0530, P J P wrote:
> >   Hello Dan, all
> > 
> > +-- On Thu, 25 Oct 2018, Daniel P. Berrangé wrote --+
> > | On Thu, Oct 25, 2018 at 10:52:56AM +0200, Gerd Hoffmann wrote:
> > | > While being at it deprecate cirrus too.
> > | > 
> > | > Reason (short version): use stdvga instead.
> > | > Verbose version:
> > | >     
> > https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful
> > | 
> > | 
> > | I don't debate the points in the blog post above that stdvga is a
> > | better choice, but I don't think that's enough to justify deprecating
> > | cirrus at this point in time, because when it then gets deleted it
> > | will break way too many existing deployments.
> > | 
> > | We need to socialize info in that blog post above more widely and
> > | especially ensure that apps are not using that by default. I don't
> > | see it being viable to formally deprecate it in QEMU any time soon
> > | though given existing usage.
> > 
> > To note, IMO there are other devices/sources in QEMU which are potential 
> > candidates for deprecation, similar to adlib etc. It'll help if we could 
> > device a process to deprecate/remove such code base. Other than maintenance 
> > it 
> > invariably also becomes source of security issues.
> > 
> > Ex.(similar to Fedora) we could announce such candidate on qemu-devel list 
> > and 
> > after review over a period of say a month, candidate will be
> > deprecated/expunged. (thinking aloud)
> 
> QEMU has a deprecation process:
> 
>   https://qemu.weilnetz.de/doc/qemu-doc.html#Deprecated-features
> 
> Most of the stuff deprecated is CLI args / monitor commands, etc where
> mgmt apps just adjust the way they are calling QEMU, so end user's VMs
> are largely not impacted.
> 
> Deprecating a device type that is widely used is not desirable because
> that will cause breakage of existing guests.  Distros are free to disable
> devices in their builds if they want to reduce the scope for CVEs in
> packages they maintain, but again they should think carefully about how
> many users they are going to break by doing so.

I should also say that QEMU as an upstream project has multiple goals.
Running KVM guests with modern PV hardware is only one of them, albeit
a widely used one. Being able to run old legacy OS with old hardware,
and running arbitrary embedded boards/devices with emulation are both
use cases that QEMU project aims to address. To eliminate all the old
"crufty" device emulation in name of improving security for KVM, would
be to eliminate core use cases of the project. THis is why we're trying
to persue the direction of making it easier for vendors to disable
features and devices they don't wish to support & thus limit their
downstream CVE exposure.

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 :|