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

[Sander Eikelenboom <linux@eikelenboom.it>]

Thursday, May 14, 2015, 2:53:17 PM, you wrote:



> On 14/05/2015 14:45, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> 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.

--
Sander

>>>                                          Unless for q35 we decide to
>>> break everything and retroactively nuke the controller.
>>>
>>> (I'm still not sure why we have backwards-compatible machine types for q35).
>> 
>> Beats me :)
>> 
>> [...]
>>