qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Michal Privoznik <mprivozn@redhat.com>,
	libvir-list@redhat.com,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH] qemu: always ask for -enable-fips
Date: Fri, 13 Dec 2013 09:09:35 -0700	[thread overview]
Message-ID: <52AB313F.4060900@redhat.com> (raw)
In-Reply-To: <20131213150650.GP23062@orkuz.home>

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

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=1035474
>>
>> Sigh, oh boy, <your favorite swear-word>. ACK.
> 
> 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 in
> 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.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

       reply	other threads:[~2013-12-13 16:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1386280486-29740-1-git-send-email-eblake@redhat.com>
     [not found] ` <52AB20AF.8010009@redhat.com>
     [not found]   ` <20131213150650.GP23062@orkuz.home>
2013-12-13 16:09     ` Eric Blake [this message]
     [not found]     ` <20131213151559.GB2801@redhat.com>
2013-12-13 16:15       ` [Qemu-devel] [libvirt] [PATCH] qemu: always ask for -enable-fips Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52AB313F.4060900@redhat.com \
    --to=eblake@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).