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

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

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

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