From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ystdc-0007lw-KE for qemu-devel@nongnu.org; Thu, 14 May 2015 09:57:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YstdZ-0003rL-Cm for qemu-devel@nongnu.org; Thu, 14 May 2015 09:57:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YstdZ-0003qo-5L for qemu-devel@nongnu.org; Thu, 14 May 2015 09:57:21 -0400 Date: Thu, 14 May 2015 15:57:15 +0200 From: "Michael S. Tsirkin" Message-ID: <20150514155054-mutt-send-email-mst@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=us-ascii Content-Disposition: inline In-Reply-To: <908546719.20150514152539@eikelenboom.it> 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, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, Paolo Bonzini , John Snow , rth@twiddle.net On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote: > > Thursday, May 14, 2015, 2:53:17 PM, you wrote: > > > > > On 14/05/2015 14:45, Markus Armbruster wrote: > >> Paolo Bonzini writes: > >> > >>> On 14/05/2015 14:02, Markus Armbruster wrote: > >>>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards > >>>> commonly don't have an FDC (depends on the Super I/O chip used). > >>>> > >>>> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt > >>>> there's a real i440FX without an FDC, but our virtual i440FX is quite > >>>> unlike a real one in other ways already. > >>> > >>> That would break libvirt for people upgrading from 2.3 to 2.4. So it's > >>> more like pc-i440fx-3.0 and pc-q35-3.0. > >> > >> What exactly breaks when? > > > libvirt expects "-nodefaults -drive if=none,id=fdd0,... -global > > isa-fdc.driveA=fdd0" to result in a machine with a working FDD. It > > doesn't know that it has to add "-machine fdc=on". > > > Besides, adding a new machine option is not the best we can do. If the > > default is "no FDC", all that is needed to add one back is -device. An > > FDC is yet another ISA device, it is possible to create one with -device. > > >> add the magic to make -global isa-fdc... auto-set the option to on. > > > That would be ugly magic. > > > The more I think about this, the more I think this is just a kneejerk > > reaction to a sensationalist announcement. The effect of this > > vulnerability on properly configured data centers (running > > non-prehistoric versions of Xen or KVM and using > > stubdom/SELinux/AppArmor properly) should be really close to zero. > > > It's a storm in a tea cup. > > > Paolo I agree. An option to disable fdc sounds like a reasonable thing to do reduce attack surface while keeping full compatibility. After all downstreams disable devices they don't want to support, too. Changing defaults just because a device had a bug does sound extreme. > 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. I support this statement for new features. Users should opt-in to them. E.g. we learned this the hard way with pvpanic. > 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. > > -- > Sander If you would change what this flag means in each release, that would achieve no useful purpose IMO. > >>> Unless for q35 we decide to > >>> break everything and retroactively nuke the controller. > >>> > >>> (I'm still not sure why we have backwards-compatible machine types for q35). > >> > >> Beats me :) > >> > >> [...] > >> > I'm fine with making them all identical. -- MST From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Thu, 14 May 2015 15:57:15 +0200 Message-ID: <20150514155054-mutt-send-email-mst@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=us-ascii Return-path: Content-Disposition: inline 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, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, Paolo Bonzini , John Snow , rth@twiddle.net List-Id: xen-devel@lists.xenproject.org On Thu, May 14, 2015 at 03:25:39PM +0200, Sander Eikelenboom wrote: > > Thursday, May 14, 2015, 2:53:17 PM, you wrote: > > > > > On 14/05/2015 14:45, Markus Armbruster wrote: > >> Paolo Bonzini writes: > >> > >>> On 14/05/2015 14:02, Markus Armbruster wrote: > >>>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards > >>>> commonly don't have an FDC (depends on the Super I/O chip used). > >>>> > >>>> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt > >>>> there's a real i440FX without an FDC, but our virtual i440FX is quite > >>>> unlike a real one in other ways already. > >>> > >>> That would break libvirt for people upgrading from 2.3 to 2.4. So it's > >>> more like pc-i440fx-3.0 and pc-q35-3.0. > >> > >> What exactly breaks when? > > > libvirt expects "-nodefaults -drive if=none,id=fdd0,... -global > > isa-fdc.driveA=fdd0" to result in a machine with a working FDD. It > > doesn't know that it has to add "-machine fdc=on". > > > Besides, adding a new machine option is not the best we can do. If the > > default is "no FDC", all that is needed to add one back is -device. An > > FDC is yet another ISA device, it is possible to create one with -device. > > >> add the magic to make -global isa-fdc... auto-set the option to on. > > > That would be ugly magic. > > > The more I think about this, the more I think this is just a kneejerk > > reaction to a sensationalist announcement. The effect of this > > vulnerability on properly configured data centers (running > > non-prehistoric versions of Xen or KVM and using > > stubdom/SELinux/AppArmor properly) should be really close to zero. > > > It's a storm in a tea cup. > > > Paolo I agree. An option to disable fdc sounds like a reasonable thing to do reduce attack surface while keeping full compatibility. After all downstreams disable devices they don't want to support, too. Changing defaults just because a device had a bug does sound extreme. > 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. I support this statement for new features. Users should opt-in to them. E.g. we learned this the hard way with pvpanic. > 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. > > -- > Sander If you would change what this flag means in each release, that would achieve no useful purpose IMO. > >>> Unless for q35 we decide to > >>> break everything and retroactively nuke the controller. > >>> > >>> (I'm still not sure why we have backwards-compatible machine types for q35). > >> > >> Beats me :) > >> > >> [...] > >> > I'm fine with making them all identical. -- MST