From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuVw-0004z8-GM for qemu-devel@nongnu.org; Thu, 14 May 2015 10:53:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsuVr-0002pg-IV for qemu-devel@nongnu.org; Thu, 14 May 2015 10:53:32 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:33948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuVr-0002pZ-DR for qemu-devel@nongnu.org; Thu, 14 May 2015 10:53:27 -0400 Date: Thu, 14 May 2015 15:52:54 +0100 From: Stefano Stabellini In-Reply-To: <5554B4B0.7030002@redhat.com> Message-ID: References: <20150513174204.GS23627@redhat.com> <5553C651.4060000@redhat.com> <20150514111825.GE3441@redhat.com> <878ucr4bb7.fsf@blackfin.pond.sub.org> <555490EE.1040802@redhat.com> <87egmjz5sl.fsf@blackfin.pond.sub.org> <55549ABD.2050202@redhat.com> <908546719.20150514152539@eikelenboom.it> <5554A946.1050906@redhat.com> <5554B4B0.7030002@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , xen-devel@lists.xensource.com, Stefano Stabellini , mst@redhat.com, Markus Armbruster , qemu-devel@nongnu.org, Sander Eikelenboom , John Snow , rth@twiddle.net 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Thu, 14 May 2015 15:52:54 +0100 Message-ID: References: <20150513174204.GS23627@redhat.com> <5553C651.4060000@redhat.com> <20150514111825.GE3441@redhat.com> <878ucr4bb7.fsf@blackfin.pond.sub.org> <555490EE.1040802@redhat.com> <87egmjz5sl.fsf@blackfin.pond.sub.org> <55549ABD.2050202@redhat.com> <908546719.20150514152539@eikelenboom.it> <5554A946.1050906@redhat.com> <5554B4B0.7030002@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <5554B4B0.7030002@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org To: Paolo Bonzini Cc: Kevin Wolf , xen-devel@lists.xensource.com, Stefano Stabellini , mst@redhat.com, Markus Armbruster , qemu-devel@nongnu.org, Sander Eikelenboom , John Snow , rth@twiddle.net List-Id: xen-devel@lists.xenproject.org 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.