From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrVJ8-0005VH-5G for qemu-devel@nongnu.org; Fri, 13 Dec 2013 11:09:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrVJ3-0004OB-AW for qemu-devel@nongnu.org; Fri, 13 Dec 2013 11:09:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrVJ3-0004O6-2h for qemu-devel@nongnu.org; Fri, 13 Dec 2013 11:09:37 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBDG9aqi021960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Dec 2013 11:09:36 -0500 Message-ID: <52AB313F.4060900@redhat.com> Date: Fri, 13 Dec 2013 09:09:35 -0700 From: Eric Blake MIME-Version: 1.0 References: <1386280486-29740-1-git-send-email-eblake@redhat.com> <52AB20AF.8010009@redhat.com> <20131213150650.GP23062@orkuz.home> In-Reply-To: <20131213150650.GP23062@orkuz.home> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kmtw5opLIljJPH8Cld9w392667jGoU6qW" Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: always ask for -enable-fips List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michal Privoznik , libvir-list@redhat.com, "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kmtw5opLIljJPH8Cld9w392667jGoU6qW Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/13/2013 08:06 AM, Jiri Denemark wrote: > On Fri, Dec 13, 2013 at 15:58:55 +0100, Michal Privoznik wrote: >> On 05.12.2013 22:54, Eric Blake wrote: >>> On a system that is enforcing FIPS, most libraries honor the >>> current mode by default. Qemu, on the other hand, refused to >>> honor FIPS mode unless you add the '-enable-fips' command >>> line option; worse, this option is not discoverable via QMP, >>> and is only present on binaries built for Linux. As far as >>> I can tell, unconditionally using the option when it is >>> available has no negative consequences (the option has no >>> change to qemu behavior except when FIPS is enabled, at which >>> point it cripples insecure VNC passwords which is the one thing >>> that libvirt must not allow when FIPS is active). >>> >>> This fixes https://bugzilla.redhat.com/show_bug.cgi?id=3D1035474 >> >> Sigh, oh boy, . ACK. >=20 > Don't we want to wait for QEMU to decide what they should be doing with= > -enable-fips to make it detectable? I tried, and got no response: https://lists.gnu.org/archive/html/qemu-devel/2013-12/msg00946.html adding qemu-devel in CC for another try. > If we push this patch, we can't > basically move into detecting the option and enabling it only when > detected since that could cause regressions for older QEMU version that= > supported the option but did not advertise it. Not necessarily. We can code things along these lines: if qemu new enough to provide binary option detection: use detection results, use if present else: if Linux: hard-code on else: assume unavailable > If we just wait for the > option to be detectable and enable it only when we detect its support i= n > QEMU, we won't enable it for all possible QEMU versions but we won't > regress in any way. I'm not worried about regressions - if someone backports binary option detection, we'll do the right thing; if they don't, then trying to the option on a build where it is not present will give a nice loud failure from qemu about an unrecognized command line option, which we would get anyways even if binary option detection is not added in qemu and our hard-code guess is wrong. I'd rather have libvirt turn the option on NOW (since it is a FIPS certification nightmare if we don't) than wait for some future qemu to fix binary option detection and hope it gets backported to any version of qemu that libvirt must drive in a FIPS environment. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Kmtw5opLIljJPH8Cld9w392667jGoU6qW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSqzE/AAoJEKeha0olJ0NqUwQH/A/ySMlGTaV2c9xPfOXTaOTi zO8juxSP2ar0gD0elE9QktcAwZhRUvVJvFksvK92htmsJL4H9r3mFIg0BIKKkR5N Hder/Or3HBhFvUDm1Pe6YDJ9EhNKErYzn+MyCpZkJxcFkYM37FElQlZsSlK4R7zu sE4jBgXr2IzPs4QjGX+LuV6SBHpncaL+i3LjAzHc1uxcai0anOG6vGnXP4xwL7wZ /OYVzm7cgImym3PYjjzFj1cY7peRDvcjMcUQ4GyQwLQHog2fUz5PxoLzwPjzocd6 ardWGgZHGHpWImtmCvihgGq5Fyk8s3Upvg++jeZNx6l2xUoP/urt380BPa2BQf0= =Q15J -----END PGP SIGNATURE----- --Kmtw5opLIljJPH8Cld9w392667jGoU6qW--