From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yst96-0003qn-6H for qemu-devel@nongnu.org; Thu, 14 May 2015 09:25:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yst92-0004f7-3N for qemu-devel@nongnu.org; Thu, 14 May 2015 09:25:52 -0400 Received: from vserver.eikelenboom.it ([84.200.39.61]:51990 helo=smtp.eikelenboom.it) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yst91-0004bI-SP for qemu-devel@nongnu.org; Thu, 14 May 2015 09:25:48 -0400 Date: Thu, 14 May 2015 15:25:39 +0200 From: Sander Eikelenboom Message-ID: <908546719.20150514152539@eikelenboom.it> In-Reply-To: <55549ABD.2050202@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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, mst@redhat.com, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, John Snow , rth@twiddle.net =0D=0AThursday, May 14, 2015, 2:53:17 PM, you wrote: > On 14/05/2015 14:45, Markus Armbruster wrote: >> Paolo Bonzini writes: >>=20 >>> 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. >>=20 >> What exactly breaks when? > libvirt expects "-nodefaults -drive if=3Dnone,id=3Dfdd0,... -global > isa-fdc.driveA=3Dfdd0" to result in a machine with a working FDD. It > doesn't know that it has to add "-machine fdc=3Don". > 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 tend to kindly disagree if you look at the broader perspective, yes it's = could=20 be a storm in a tea cup, but there seems to be a pattern. From=20a "cmdline user" / "platform emulation" point of view i can imagine = that some sort of=20 auto configuration / bundling in platforms is necessary (to limit the lengt= h of=20 the cmdline to be supplied). But from a library / toolstack point of view it's quite nasty if *all* more= or=20 less obscure options have to actively disabled. It's quite undoable, not to= mention what happens when new ones get added.=20 From=20this 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 g= et=20 there so far, but that doesn't seem to=20 It's not the first CVE that has come from this "you have to actively disabl= e all=20 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, th= at=20 requires them to be very verbose, explicit and specific in what they actual= ly=20 want, could be valuable. -- Sander >>> 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). >>=20 >> Beats me :) >>=20 >> [...] >>=20 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults Date: Thu, 14 May 2015 15:25:39 +0200 Message-ID: <908546719.20150514152539@eikelenboom.it> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <55549ABD.2050202@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, mst@redhat.com, Stefano Stabellini , Markus Armbruster , qemu-devel@nongnu.org, John Snow , rth@twiddle.net List-Id: xen-devel@lists.xenproject.org =0D=0AThursday, May 14, 2015, 2:53:17 PM, you wrote: > On 14/05/2015 14:45, Markus Armbruster wrote: >> Paolo Bonzini writes: >>=20 >>> 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. >>=20 >> What exactly breaks when? > libvirt expects "-nodefaults -drive if=3Dnone,id=3Dfdd0,... -global > isa-fdc.driveA=3Dfdd0" to result in a machine with a working FDD. It > doesn't know that it has to add "-machine fdc=3Don". > 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 tend to kindly disagree if you look at the broader perspective, yes it's = could=20 be a storm in a tea cup, but there seems to be a pattern. From=20a "cmdline user" / "platform emulation" point of view i can imagine = that some sort of=20 auto configuration / bundling in platforms is necessary (to limit the lengt= h of=20 the cmdline to be supplied). But from a library / toolstack point of view it's quite nasty if *all* more= or=20 less obscure options have to actively disabled. It's quite undoable, not to= mention what happens when new ones get added.=20 From=20this 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 g= et=20 there so far, but that doesn't seem to=20 It's not the first CVE that has come from this "you have to actively disabl= e all=20 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, th= at=20 requires them to be very verbose, explicit and specific in what they actual= ly=20 want, could be valuable. -- Sander >>> 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). >>=20 >> Beats me :) >>=20 >> [...] >>=20