From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33094) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ystbt-0006Dp-IL for qemu-devel@nongnu.org; Thu, 14 May 2015 09:55:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ystbq-0001se-C2 for qemu-devel@nongnu.org; Thu, 14 May 2015 09:55:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ystbp-0001rw-VQ for qemu-devel@nongnu.org; Thu, 14 May 2015 09:55:34 -0400 Message-ID: <5554A946.1050906@redhat.com> Date: Thu, 14 May 2015 15:55:18 +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> In-Reply-To: <908546719.20150514152539@eikelenboom.it> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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: Sander Eikelenboom Cc: Kevin Wolf , xen-devel@lists.xensource.com, mst@redhat.com, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, John Snow , rth@twiddle.net 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? 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. 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 15:55:18 +0200 Message-ID: <5554A946.1050906@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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <908546719.20150514152539@eikelenboom.it> 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: Sander Eikelenboom Cc: Kevin Wolf , xen-devel@lists.xensource.com, mst@redhat.com, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, John Snow , rth@twiddle.net List-Id: xen-devel@lists.xenproject.org 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? 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. 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.