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

From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	xen-devel@lists.xensource.com, mst@redhat.com,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Sander Eikelenboom <linux@eikelenboom.it>,
	John Snow <jsnow@redhat.com>,
	rth@twiddle.net
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults
Date: Thu, 14 May 2015 16:44:00 +0200	[thread overview]
Message-ID: <5554B4B0.7030002@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1505141530040.20496@kaball.uk.xensource.com>

On 14/05/2015 16:39, Stefano Stabellini wrote:
> 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.

Floppy drives aren't being emulated; the controller is.  Same for IDE,
so why single out the FDD controller?

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

Sure; OTOH, treating hypervisor and QEMU escapes would be very silly, if
QEMU has been properly protected (through any combination of stubdoms,
LSM, seccomp, ...).

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