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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote:
> 
> Thursday, May 14, 2015, 2:53:17 PM, you wrote:
> 
> 
> 
> > On 14/05/2015 14:45, Markus Armbruster wrote:
> >> Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
> >> 
> >>> On 14/05/2015 14:02, Markus Armbruster wrote:
> >>>>   It should certainly be off for pc-q35-2.4 and newer.  Real Q35 boards
> >>>>   commonly don't have an FDC (depends on the Super I/O chip used).
> >>>>
> >>>>   We may want to keep it off for pc-i440fx-2.4 and newer.  I doubt
> >>>>   there's a real i440FX without an FDC, but our virtual i440FX is quite
> >>>>   unlike a real one in other ways already.
> >>>
> >>> That would break libvirt for people upgrading from 2.3 to 2.4.  So it's
> >>> more like pc-i440fx-3.0 and pc-q35-3.0.
> >> 
> >> What exactly breaks when?
> 
> > libvirt expects "-nodefaults -drive if=none,id=fdd0,... -global
> > isa-fdc.driveA=fdd0" to result in a machine with a working FDD.  It
> > doesn't know that it has to add "-machine fdc=on".
> 
> > Besides, adding a new machine option is not the best we can do.  If the
> > default is "no FDC", all that is needed to add one back is -device.  An
> > FDC is yet another ISA device, it is possible to create one with -device.
> 
> >> add the magic to make -global isa-fdc... auto-set the option to on.
> 
> > That would be ugly magic.
> 
> > The more I think about this, the more I think this is just a kneejerk
> > reaction to a sensationalist announcement.  The effect of this
> > vulnerability on properly configured data centers (running
> > non-prehistoric versions of Xen or KVM and using
> > stubdom/SELinux/AppArmor properly) should be really close to zero.
> 
> > It's a storm in a tea cup.
> 
> > Paolo
> 
> 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. 
> 
> 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.

That doesn't really scale to be honest - a -no-defaults-now-for-real
basically means deleting the entire concept of machine types, and
requiring every single aspect of the base chipset to be explicitly
configured. That's certainly possible but its a massive code job for
QEMU and the management apps using QEMU. In fact the amount of code
we'll have to write to achieve that in both QEMU and libvirt would
probably introduce more bugs, so its questionable whether it would
even be a net win in terms of reducing CVEs.

Even if you disable some more default devices, the amount of code
that'll be taken out of the attack surface is going to be tiny
compared to the amount of code that will always remain due to the
feature needs of the OS.

So even with more default devices disabled, we have to assume that
we will continue to see CVEs in stuff that remains and so must ensure
we can mitigate the risks such that they have negligble impact on
people who have deployed QEMU. ie the goal should be that a guest
attack on QEMU ends up being nothing worse than a denial of service
on attacker themselves.

This is why using technologies such as SELinux, AppArmour, StubDomains
and seccomp are so important when running QEMU. There is scope for
applying more such as kernel namespaces to further isolate QEMU
processes from each other.

With these defences in place these kind of bugs really do become a
storm in a teacup as Paolo suggests. That's not to say they are not
important to fix, but we need to have some perspective about where
efforts should be best focused to reduce our security risk.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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