Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 14 May 2015, Paolo Bonzini wrote:
> On 14/05/2015 15:25, Sander Eikelenboom wrote:
> > I tend to kindly disagree if you look at the broader perspective, yes it's 
> > could 
> > be a storm in a tea cup, but there seems to be a pattern.
> > 
> > From a "cmdline user" / "platform emulation" point of view i can imagine 
> > that some sort of 
> > auto configuration / bundling in platforms is necessary (to limit the 
> > length of 
> > the cmdline to be supplied).
> > 
> > But from a library / toolstack point of view it's quite nasty if *all* more 
> > or 
> > less obscure options have to actively disabled. It's quite undoable, not to 
> > mention what
> > happens when new ones get added. 
> 
> Where do you stop?

At this stage I would be happy enough if no floppy drives were actually
emulated when the user asks for none.


> Do you want to disable ACPI by default?  It's a relatively large amount
> of code, but for most modern guests it is necessary.
> 
> Besides, removing just the floppy drive makes little sense.  The
> following devices remain with -nodefaults:
> 
> - an HPET
> 
> - the power management device, which includes an I2C controller
> 
> - an IDE controller
> 
> - a keyboard controller
> 
> - the magic VMware I/O port
> 
> - the PC speaker (!)
> 
> - the legacy PIT
> 
> - the real-time clock
> 
> - the two PICs and IOAPIC
> 
> Of all these, most guests will only use the PM device (maybe) and a
> small subset of the RTC.  At the very least, the IDE controller, PC
> speaker and the HPET should be removed by -nodefaults-i-mean-it.  If
> you're using UEFI firmware, probably you could remove everything except
> the PM device---maybe the RTC and the IOAPIC.  At this point this is not
> -nodefaults-i-mean-it, it's a different machine type altogether and it's
> remarkably different from a PC.
> 
> Reducing the attack surface is always nice, but hypervisor and device
> model bugs are going to exist forever.  The amount of code for legacy
> devices is all in all not that big, and I can hardly recall other
> vulnerabilities in there.  This is why I say it's a knee-jerk reaction.
> 
> It is the intrinsic problem of virtualization mentioned in the famous
> quote of Theo de Raadt(*).  Even if you do PV like Xen or Hyper-V, you
> have less or no QEMU code but you throw more hypervisor code in
> untrusted hands (hypervisor bugs exist, e.g. CVE-2012-4539,
> CVE-2012-5510 or CVE-2013-1964).
> 
>       (*) Which of course misses the point of virtualization
>           altogether.  Once you have established that you need
>           more density, choosing containers vs. virtualization
>           is a gamble on whether you prefer more moving parts and
>           more layers that have to be broken (more isolation), or
>           fewer moving parts and less isolation.

Sure, but it is harder to write a device emulator in a secure fashion
than a brand new PV interface, that can be designed with security in
mind from scratch. The number of VM escaping CVEs affecting Xen PV
interfaces is extremely low, I think it was just two since the start of
the project.



> > From this PoV it would be better to have to actively enable all the stuff 
> > you want.
> > 
> > At least Xen seemed to have taken the "no-defaults" as the best option to 
> > get 
> > there so far, but that doesn't seem to 
> > 
> > It's not the first CVE that has come from this "you have to actively 
> > disable all 
> > you don't want to happen" and probably won't be the last.
> > 
> > So a "-no-defaults-now-for-real" option/mode for libraries / toolstacks, 
> > that 
> > requires them to be very verbose, explicit and specific in what they 
> > actually 
> > want, could be valuable.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel