From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuIX-0007d0-9e for qemu-devel@nongnu.org; Thu, 14 May 2015 10:39:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsuIR-000178-AI for qemu-devel@nongnu.org; Thu, 14 May 2015 10:39:41 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:52218) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsuIR-000168-2Y for qemu-devel@nongnu.org; Thu, 14 May 2015 10:39:35 -0400 Date: Thu, 14 May 2015 15:39:04 +0100 From: Stefano Stabellini In-Reply-To: <5554A946.1050906@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> 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 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. > Do you want to disable ACPI by default? It's a relatively large amount > of code, but for most modern guests it is necessary. > > Besides, removing just the floppy drive makes little sense. The > following devices remain with -nodefaults: > > - an HPET > > - the power management device, which includes an I2C controller > > - an IDE controller > > - a keyboard controller > > - the magic VMware I/O port > > - the PC speaker (!) > > - the legacy PIT > > - the real-time clock > > - the two PICs and IOAPIC > > Of all these, most guests will only use the PM device (maybe) and a > small subset of the RTC. At the very least, the IDE controller, PC > speaker and the HPET should be removed by -nodefaults-i-mean-it. If > you're using UEFI firmware, probably you could remove everything except > the PM device---maybe the RTC and the IOAPIC. At this point this is not > -nodefaults-i-mean-it, it's a different machine type altogether and it's > remarkably different from a PC. > > Reducing the attack surface is always nice, but hypervisor and device > model bugs are going to exist forever. The amount of code for legacy > devices is all in all not that big, and I can hardly recall other > vulnerabilities in there. This is why I say it's a knee-jerk reaction. > > It is the intrinsic problem of virtualization mentioned in the famous > quote of Theo de Raadt(*). Even if you do PV like Xen or Hyper-V, you > have less or no QEMU code but you throw more hypervisor code in > untrusted hands (hypervisor bugs exist, e.g. CVE-2012-4539, > CVE-2012-5510 or CVE-2013-1964). > > (*) Which of course misses the point of virtualization > altogether. Once you have established that you need > more density, choosing containers vs. virtualization > is a gamble on whether you prefer more moving parts and > more layers that have to be broken (more isolation), or > fewer moving parts and less isolation. 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. > > 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: Stefano Stabellini Subject: Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Thu, 14 May 2015 15:39:04 +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> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Return-path: In-Reply-To: <5554A946.1050906@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 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. > Do you want to disable ACPI by default? It's a relatively large amount > of code, but for most modern guests it is necessary. > > Besides, removing just the floppy drive makes little sense. The > following devices remain with -nodefaults: > > - an HPET > > - the power management device, which includes an I2C controller > > - an IDE controller > > - a keyboard controller > > - the magic VMware I/O port > > - the PC speaker (!) > > - the legacy PIT > > - the real-time clock > > - the two PICs and IOAPIC > > Of all these, most guests will only use the PM device (maybe) and a > small subset of the RTC. At the very least, the IDE controller, PC > speaker and the HPET should be removed by -nodefaults-i-mean-it. If > you're using UEFI firmware, probably you could remove everything except > the PM device---maybe the RTC and the IOAPIC. At this point this is not > -nodefaults-i-mean-it, it's a different machine type altogether and it's > remarkably different from a PC. > > Reducing the attack surface is always nice, but hypervisor and device > model bugs are going to exist forever. The amount of code for legacy > devices is all in all not that big, and I can hardly recall other > vulnerabilities in there. This is why I say it's a knee-jerk reaction. > > It is the intrinsic problem of virtualization mentioned in the famous > quote of Theo de Raadt(*). Even if you do PV like Xen or Hyper-V, you > have less or no QEMU code but you throw more hypervisor code in > untrusted hands (hypervisor bugs exist, e.g. CVE-2012-4539, > CVE-2012-5510 or CVE-2013-1964). > > (*) Which of course misses the point of virtualization > altogether. Once you have established that you need > more density, choosing containers vs. virtualization > is a gamble on whether you prefer more moving parts and > more layers that have to be broken (more isolation), or > fewer moving parts and less isolation. 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. > > 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. >