From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuN1-0002QW-Em for qemu-devel@nongnu.org; Thu, 14 May 2015 10:44:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsuMy-0007ap-5o for qemu-devel@nongnu.org; Thu, 14 May 2015 10:44:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuMx-0007a7-V3 for qemu-devel@nongnu.org; Thu, 14 May 2015 10:44:16 -0400 Message-ID: <5554B4B0.7030002@redhat.com> Date: Thu, 14 May 2015 16:44:00 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Stefano Stabellini Cc: Kevin Wolf , xen-devel@lists.xensource.com, mst@redhat.com, Markus Armbruster , qemu-devel@nongnu.org, Sander Eikelenboom , John Snow , rth@twiddle.net 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. >> From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Thu, 14 May 2015 16:44:00 +0200 Message-ID: <5554B4B0.7030002@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Stefano Stabellini Cc: Kevin Wolf , xen-devel@lists.xensource.com, mst@redhat.com, Markus Armbruster , qemu-devel@nongnu.org, Sander Eikelenboom , John Snow , rth@twiddle.net List-Id: xen-devel@lists.xenproject.org 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. >>