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

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

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?

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.

Paolo

> 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