Bug 1035474

This flag in QEMU is utterly retarded and should not exist. If the host is running in FIPS mode (as indicated by the kernel) then QEMU should use FIPS mode unconditionally to match what the crypto libraries are already doing. If the host isn't FIPS mode then it should not do anything. This flag is a solution in search of a purpose.

(In reply to Daniel Berrange from comment #2)
> This flag in QEMU is utterly retarded and should not exist. If the host is
> running in FIPS mode (as indicated by the kernel) then QEMU should use FIPS
> mode unconditionally to match what the crypto libraries are already doing.
> If the host isn't FIPS mode then it should not do anything. This flag is a
> solution in search of a purpose.

I agree that the flag is ridiculous, but upstream made it a requirement on accepting the FIPS detection code.  On the virt-devel list, we are currently discussing the possibility of making the "-enable-fips" option default to "on", but that would diverge from upstream.

Does qemu even provide a way to query whether the command line option exists or not?  Without a QMP query method, the only way to find out is to try qemu with it, and on failure fall back to avoiding it, which is painful if the option ever gets removed in future versions.  I agree that libvirt should always supply the option for older qemu, though.

(In reply to Eric Blake from comment #4)
> Does qemu even provide a way to query whether the command line option exists
> or not?

To the best of my knowledge, no.

> Without a QMP query method, the only way to find out is to try qemu
> with it, and on failure fall back to avoiding it, which is painful if the
> option ever gets removed in future versions.  I agree that libvirt should
> always supply the option for older qemu, though.

Considering that upstream was very insistent that the command line option be added, I find it very doubtful that it would be removed in the future.

Upstream proposed patch:
https://www.redhat.com/archives/libvir-list/2013-December/msg00353.html

Upstream v2:
https://www.redhat.com/archives/libvir-list/2013-December/msg00833.html

Option 1 in POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-December/msg00812.html

although it may be worth waiting for option 2, which backports vircapabilitestest, for comparison.

Option 2 turned out to be rather invasive; I'd rather skip the qemucapabilitiestest in the option 1 backport than introduce the additional risk of 20+ patches to enhance the testsuite.

Can reproduce with:
libvirt-1.1.1-17.el7.x86_64

Steps:

1. Prepare a guest using vnc and with a password.

2. Enable FIPS mode.
#yum install dracut-fips
#rpm -qa |grep dracut
dracut-network-033-40.el7.x86_64
dracut-033-40.el7.x86_64
dracut-fips-033-40.el7.x86_64
dracut-config-rescue-033-40.el7.x86_64
#setting configuring "PRELINKING=no" in the /etc/sysconfig/prelink configuration file
#prelink -u -a
#dracut -f

add "fips=1" and boot partition in kernel command line

linux16 /vmlinuz-3.10.0-54.el7.x86_64 root=/dev/mapper/rhel_intel--5205--32--1-root ro rd.lvm.lv=rhel_intel-5205-32-1/swap console=tty0 vconsole.keymap=us reboot=pci console=ttyS0,115200 vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel_intel-5205-32-1/root biosdevname=0 crashkernel=256M LANG=en_US.UTF-8 fips=1 boot=/dev/sda1

reboot host

3. Check fips:
# cat /proc/sys/crypto/fips_enabled
1

4. Try to start the guest.
# virsh start $vm

5. Check the qemu cmdline
# ps -ef | grep $vm

Result:
The guest start successfully, and there is no "-enable-fips" in qemu cmdline.


Verify with:
libvirt-1.1.1-18.el7.x86_64

Steps:
As the steps above.

Result:
1.
The guest cannot start, get error:
error: Failed to start domain rhel6u5
error: internal error: early end of file from monitor: possible problem:
qemu-kvm: Failed to start VNC server on `unix:/var/lib/libvirt/qemu/rhel6u5.vnc,password': VNC password auth disabled due to FIPS mode, consider using the VeNCrypt or SASL authentication methods as an alternative
2.If delete the vnc-passwd,and try to start the guest , the guest can start successfully.
And can find "-enable-fips" in qemu cmdline like:
qemu      4128     1 28 11:46 ?        00:00:18 /usr/libexec/qemu-kvm -name rhel6u5 -S -enable-fips -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 6c58ee29-3c2c-431e-93b2-403409566272 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel6u5.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/rhel6u5.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e1:59:9e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc unix:/var/lib/libvirt/qemu/rhel6u5.vnc -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
3.
The guest can start if disable fips mode and there is no "-enable-fips" in qemu cmdline.

As the result, set VERIFIED.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.