On 12/13/2013 08:22 AM, Jiri Denemark wrote:
> QEMU already detects current FIPs enablement via the file
> /proc/sys/crypto/fips_enabled, but only if you use --enable-fips.
> This is really stupid given that all the crypto libraries that
> QEMU uses unconditonally look at the proc file. So by having this
> flag QEMU is in the insane situation where if FIPS is enabled then
> part of QEMU will honour FIPS settings but other parts of QEMU will
> not honour it until you pass --enable-fips. Insanity. So having
> libvirt pass --enable-fips unconditionally fixes this insanity as
> much as possible. Better yet if QEMU were to just remove the
> pointless --enable-fips arg and just respect the fips_enabled
> sysctl flag by default.
Of course, I don't question this part. I just don't like the black magic
we use to decide whether we can use -enable-fips or not and if we go
this black route, we will have to stick with it even if QEMU provides a
proper way of detecting -enable-fips. We could only use the detection in
case our black magic decides the option is not supported.
The only black magic involved is:
For any version of qemu that does not report binary flags, repeat the
encoding used in those versions of qemu for whether the option exists.
That happens to be hard-coded to being compiled for Linux, for versions
1.2 through the present, and that set of versions also happens to be the
set of qemu that supports QMP probing (so no -help scraping needed). If
future qemu is enhanced to support binary flag probing via QMP, then
that will take precedence (and work regardless of platform); where it is
only when we can't detect the newer means for binary flag scraping do we
have to fall back to our black magic reproduction of qemu behavior. I
don't like it either, but I don't see any alternatives.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org