qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: -enablefips
Date: Wed, 24 Jun 2020 10:05:37 +0100	[thread overview]
Message-ID: <20200624090537.GF774096@redhat.com> (raw)
In-Reply-To: <7816f22f-2872-06ef-f7ef-40add5a34040@redhat.com>

On Tue, Jun 23, 2020 at 11:51:09PM -0400, John Snow wrote:
> I never knew what this option did, but the answer is ... strange!
> 
> It's only defined for linux, in os-posix.c. When called, it calls
> fips_set_state(true), located in osdep.c.
> 
> This will read /proc/sys/crypto/fips_enabled and set the static global
> 'fips_enabled' to true if this setting is on.
> 
> (Tangent: what does *this* setting actually control? Should QEMU
> meaningfully change its behavior when it's set?)
> 
> This static global is exposed via the getter fips_get_state(). This
> function is called only by vnc.c, and appears to disable the use of the
> password option for -vnc.
> 
> This seems very high-level and abstract for something that ultimately
> only disables VNC password authentication. Is this misleadingly abstract?
> 
> The docs state:
> "enable FIPS 140-2 compliance"
> 
> Like hell it does.

It prevents the use of non-FIPS crypto in QEMU, so it isn't that
inaccurate.

> Can we deprecate this? It was added in 2012 and never seemed to pursue
> the mission laid out in the help file. If we do still want it, the
> documentation should be changed dramatically to reflect what it actually
> does.
> 
> This is so at risk of bit-rot, and a misleading crypto flag is certainly
> worse than no crypto flag. I think it should just go.

I think it can go.

FIPS support in QEMU is only needed if using our own crypto code which
lacks FIPS compliance, which essentially means our Single DES impl.

Anyone who cares about FIPS should be building QEMU with crypto provided
by libgcrypt. This will take care of FIPS compliance automatically,
so there's nothing QEMU needs do itself.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



      parent reply	other threads:[~2020-06-24  9:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  3:51 -enablefips John Snow
2020-06-24  6:49 ` -enablefips Gerd Hoffmann
2020-06-24  8:34   ` -enablefips Markus Armbruster
2020-06-24  8:58   ` -enablefips Daniel P. Berrangé
2020-06-24 15:09   ` -enablefips John Snow
2020-06-24  9:05 ` Daniel P. Berrangé [this message]

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=20200624090537.GF774096@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kraxel@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).