qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefano Stabellini
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults
Date: Thu, 14 May 2015 15:52:54 +0100
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Thu, 14 May 2015, Paolo Bonzini wrote:
> 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?

The problem is that floppy drive emulation code in the controller is not
completely turned off even when no drives are available, see: 

http://marc.info/?l=xen-devel&m=143155839722714&w=2

Instead of disentangling the controller code, I am taking the easy route
of removing the 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, ...).

That is true, but I don't know how many distros setup up selinux,
stubdoms, etc properly by default, but I am guessing not that many.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]