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

["Michael S. Tsirkin" <mst@redhat.com>]

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@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 agree.  An option to disable fdc sounds like a reasonable thing to do
reduce attack surface while keeping full compatibility. After all
downstreams disable devices they don't want to support, too.  Changing
defaults just because a device had a bug does sound extreme.

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

I support this statement for new features. Users should opt-in to them.
E.g. we learned this the hard way with pvpanic.

> 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

If you would change what this flag means in each release, that would
achieve no useful purpose IMO.

> >>>                                          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 :)
> >> 
> >> [...]
> >> 
> 

I'm fine with making them all identical.

-- 
MST