Description of problem: Unable to start KVM guests when running kernel in FIPS mode. Version-Release number of selected component (if applicable): RHEL 5.8 and previous. How reproducible: 1. Install RHEL 5 up to 5.8 2. Follow steps in https://access.redhat.com/knowledge/articles/38655 # cat /proc/sys/crypto/fips_enabled 1 3. # virsh create /etc/libvirt/qemu/fipstest1.xml error: Failed to create domain from /etc/libvirt/qemu/fipstest1.xml error: internal error Process exited while reading console log output: libgcrypt DES cipher initialization error Actual results: Expected results: Additional info:
Process exited while reading console log output indicates that qemu exited, so I'm changing the component.
Also, this sounds like its complaining about a request to use the DES cipher, which is forbidden in FIPS-140. Whatever it is probably should have been using TDES which is approved under fips.
Can you attach the guest's XML definition file?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Hi Trent, Thank you for taking the time to enter a bug report with us. We do appreciate the feedback and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for getting support, and as such we are not able to make any guarantees as to the timeliness or suitability of a resolution. If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain that it gets the proper attention and prioritization to assure a timely resolution. For information on how to contact the Red Hat production support team, please see: https://www.redhat.com/support/process/production/#howto Thanks, Ronen.
To be fair, I asked for this bug report based on a discussion on a mail list.
Steve thanks, Since we want to make minimal changes to RHEL5.9 in order to keep it stable, and this looks like a non-supported scenario (see comment#2), and in any case, it will not affect a running guest, I am closing this bug. Ronen.
(In reply to comment #5) > Can you attach the guest's XML definition file? Can someone provide a copy of the offending guests XML definition, or does it happen with *every* guest?
Hi trent.mcgrath, Can you provide XML file, I can not reproduce it with attached xml 1. fips setup can not get details from https://access.redhat.com/knowledge/articles/38655 setup fips with the following steps 1. mkinitrd --with-fips -f /boot/initrd-$(uname -r).img $(uname -r) 2. Add “fips=1” to grub kernel boot line 3. reboot guest # cat /proc/sys/crypto/fips_enabled 1 2. guest 2.6.18-308.1.2.el5 x86_64 3. host 2.6.18-308.1.1.el5 kvm-83-249.el5 libvirt-0.8.2-25.el5 4. xml file (attached)
Created attachment 577939 [details] xml file
Created attachment 578157 [details] F16 x86_64 guest definition F16 x86_64 guest definition used to reproduce the problem described by the reporter.
A quick update - I am able to reproduce the problem using RHEL5.8 x86_64 and a F16 x86_64 guest (see the attachment in comment #18): # uname -a Linux alice 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 ... # cat /proc/sys/crypto/fips_enabled 1 # virsh create /etc/libvirt/qemu/f16-test-1.xml error: Failed to create domain from /etc/libvirt/qemu/f16-test-1.xml error: internal error Process exited while reading console log output: libgcrypt DES cipher initialization error I will update the bug when I have more to report.
make a mistake, host is in fips mode not guest, reproduce it with rhel5.8 guest error: Failed to start domain 5.8 error: internal error Process exited while reading console log output: libgcrypt DES cipher initialization error
From libgcrypt security policy.. In Approved mode, the module will support the following Approved Cryptographic functions: ● Triple-DES, encryption/decryption (ECB, CBC, OFB, CFB, CTR) ● AES 128/192/256 bits, encryption/decryption (ECB, CBC, OFB, CFB, CTR) ● RSA key generation, signature generation (PKCS #1.5), signature verification (PKCS #1.5) ● SHA 1/224/256/384/512 ● DSA (PQG, Sig gen, Sig Ver) ● HMAC-SHA-1/224/256/384/512 ● Random Number Generation (ANSI X9.31)
Okay, that sounds reasonable. To be clear, when in FIPS mode, QEMU will disable VNC password authentication and emit a syslog message to that effect.
I wonder if that is the right thing to do. Dropping the password might make the connection available without any authentication. I think the right action is to simply output a helpful error message and exit. Let the admin either change the authentication method or stop using FIPS mode. Let them decide how to handle it. But the key is outputting a helpful error message so they have a clue. Man page updates will help so that we can point to them that this is the design.
I should have been more clear in comment 31; beyond disabling VNC password authentication and emitting a syslog message about operating in "FIPS mode", QEMU will exit if configured to run as a password authenticated VNC server. If QEMU is configured to run as an unauthenticated VNC server then it will continue to run as expected.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: We should add a note to the release notes indicating that VNC password authentication is disabled when the system is operating in "FIPS mode".
A fix for this has been accepted upstream and a backport for RHEL5 has been posted for internal review.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -We should add a note to the release notes indicating that VNC password authentication is disabled when the system is operating in "FIPS mode".+VNC password authentication is disabled when the host system is operating in FIPS mode. QEMU exits if it is configured to run as a password-authenticated VNC server; if QEMU is configured to run as an unauthenticated VNC server, it will continue to run as expected.
Reproduced on kvm-83-260.el5: [root@localhost nfs]# /usr/libexec/qemu-kvm -hda RHEL-Server-5.9-64-virtio.qcow2 -monitor stdio -vnc :10,password libgcrypt DES cipher initialization error Verified on kvm-83-262.el5: [root@localhost nfs]# /usr/libexec/qemu-kvm -hda RHEL-Server-5.9-64-virtio.qcow2 -monitor stdio -vnc :10,password VNC password auth disabled due to FIPS mode, consider using the VeNCrypt or SASL authentication methods as an alternative
and on kvm-83-262.el5: [root@localhost nfs]# /usr/libexec/qemu-kvm -hda RHEL-Server-5.9-64-virtio.qcow2 -monitor stdio -vnc :10 QEMU 0.9.1 monitor - type 'help' for more information (qemu)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0007.html