Description of problem: RHV 4.4. FIPS install leaves UUID blank in grub after setting kernel option Version-Release number of selected component (if applicable): 4.4.6.2 How reproducible: I have not been able to reproduce in lab because of lab infrastructure and does not work on the nested lab. Customer can reproduce but has the environment running without FIPS in order to move forward on project. Steps to Reproduce: 1. Install RHVH deploy host Follow the on-screen instructions to select VPP - Protection Profile for Virtualization 1.0 for Red Hat Enterprise Linux Hypervisor (RHELH) # fips-mode-setup --check FIPS mode is enabled. 2. Perform hosted-engine --deploy from command line and choose Openscap 3. Enable FIPS kernel parms on host through the admin portal https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/enabling_fips_using_the_rhv_manager_appendix_fips Actual results: Before applying the kernel param change by editing the host in the admin portal under the Kernel tab and enabling FIPS, the kernel command line below: Current kernel CMD line: BOOT_IMAGE=(hd0,gpt2)//rhvh-4.4.6.2-0.20210615.0+1/vmlinuz-4.18.0-305.3.1.el8_4.x86_64 crashkernel=auto rd.lvm.lv=rhvh_vfphvt001/rhvh-4.4.6.2-0.20210615.0+1 fips=1 boot=UUID=8793c9d5-fff5-46ae-b0d8-0b5611b4914f root=/dev/rhvh_vfphvt001/rhvh-4.4.6.2-0.20210615.0+1 rootflags=discard img.bootid=rhvh-4.4.6.2-0.20210615.0+1 After it is applied and the host is rebooted the boot=UUID is left blank. [hhaberma@supportshell log]$ egrep 'mock|BOOT_IMAGE|boot=UUID|fips=1' messages |tr -s ' ' '\n' |egrep 'mock|BOOT_IMAGE|boot=UUID|fips=1' |tail -n 19 (mockbuild.eng.bos.redhat.com) BOOT_IMAGE=(hd0,gpt2)//rhvh-4.4.6.2-0.20210615.0+1/vmlinuz-4.18.0-305.3.1.el8_4.x86_64 fips=1 boot=UUID=8793c9d5-fff5-46ae-b0d8-0b5611b4914f BOOT_IMAGE=(hd0,gpt2)//rhvh-4.4.6.2-0.20210615.0+1/vmlinuz-4.18.0-305.3.1.el8_4.x86_64 fips=1 boot=UUID=8793c9d5-fff5-46ae-b0d8-0b5611b4914f BOOT_IMAGE=(hd0,gpt2)//rhvh-4.4.6.2-0.20210615.0+1/vmlinuz-4.18.0-305.3.1.el8_4.x86_64 fips=1 boot=UUID=8793c9d5-fff5-46ae-b0d8-0b5611b4914f 'fips=1 boot=UUID=' Expected results: For "UUID=8793c9d5-fff5-46ae-b0d8-0b5611b4914f" to retain its value in the kernel command line after the kernel option for FIPS is enabled in admin portal per documentation when the host is rebooted. Current kernel CMD line: BOOT_IMAGE=(hd0,gpt2)//rhvh-4.4.6.2-0.20210615.0+1/vmlinuz-4.18.0-305.3.1.el8_4.x86_64 crashkernel=auto rd.lvm.lv=rhvh_vfphvt001/rhvh-4.4.6.2-0.20210615.0+1 fips=1 boot=UUID=8793c9d5-fff5-46ae-b0d8-0b5611b4914f root=/dev/rhvh_vfphvt001/rhvh-4.4.6.2-0.20210615.0+1 rootflags=discard img.bootid=rhvh-4.4.6.2-0.20210615.0+1 Additional info:
I believe "Enable FIPS kernel parms on host through the admin portal" (step 3 from Steps to Reproduce) is not required, if a security profile is already selected during the host deployment. Liran, can you please check why the UUID is empty when FIPS mode is selected (see attachment in comment 1)?
If the host already have FIPS enabled, it is not required to change it on the Host edit in the UI. Given the information I can't tell why it's empty. Please provide the output of VDSM getCapabilities (vdsm-client Host getCapabilities | grep boot_uuid) and the output of the vds_dynamic in the DB(select boot_uuid, rpm_version, fips_enabled from vds_dynamic where vds_id='<HOST_ID>';) Also, logs might be useful.
Verified with: ovirt-engine-4.4.10.5-0.2.el8ev.noarch Steps: 1. Prepare a host with FIPS enabled [root@janus05 ~]# fips-mode-setup --check FIPS mode is enabled. [root@janus05 ~]# cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-348.13.1.el8_5.x86_64 root=/dev/mapper/VolGroup01-root ro nofb intel_iommu=on default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024 console=tty0 crashkernel=auto resume=UUID=b86cad60-b822-47b5-969e-c7167dd17de0 rd.lvm.lv=VolGroup01/root biosdevname=0 console=ttyS1,115200 fips=1 boot=UUID=6068667c-b186-418a-8299-38494b789e51 2. Enable FIPS kernel params on admin portal according to steps in https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/administration_guide/enabling_fips_using_the_rhv_manager_appendix_fips 3. Check host kernel cmdline after reboot Results: 1. When FIPS mode checkbox is selected on kernel tab of Edit Host window, only "fips=1" is presented in the "Kernel command line" box. 2. After reboot, there is no blank 'boot=UUID=' in the host kernel cmdline: [root@janus05 ~]# cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-348.13.1.el8_5.x86_64 root=/dev/mapper/VolGroup01-root ro nofb intel_iommu=on default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024 console=tty0 crashkernel=auto resume=UUID=b86cad60-b822-47b5-969e-c7167dd17de0 rd.lvm.lv=VolGroup01/root biosdevname=0 console=ttyS1,115200 boot=UUID=6068667c-b186-418a-8299-38494b789e51 fips=1
Hi Liran, please review this doc text (for the Errata) Previously, when preparing a host with FIPS kernel parameters enabled, following reboot, the boot UUID parameter was left blank. In this release, the UUID is already present in the kernel arguments, and enabling FIPS does not change the UUID following reboot.
(In reply to Eli Marcus from comment #11) > Hi Liran, > please review this doc text (for the Errata) > > > Previously, when preparing a host with FIPS kernel parameters enabled, > following reboot, the boot UUID parameter was left blank. > In this release, the UUID is already present in the kernel arguments, and > enabling FIPS does not change the UUID following reboot. Previously, when preparing a host with FIPS kernel parameters enabled and boot UUID exists on the kernel parameters, following reboot, the boot UUID parameter was left blank. In this release, if UUID is already present in the kernel arguments, enabling FIPS does not change the UUID following reboot. I tried to emphasize that it's only when enabling FIPS and having the UUID already set pre-reboot. When the UUID doesn't exist we add it.
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 (Low: RHV Manager (ovirt-engine) security update [ovirt-4.4.10-1]), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0475
Due to QE capacity, we are not going to cover this issue in our automation