Red Hat Bugzilla – Full Text Bug Listing
|Summary:||dracut parameter "boot=<boot device>" broken for FIPS mode|
|Product:||Red Hat Enterprise Linux 6||Reporter:||Stephan Mueller <smueller>|
|Component:||dracut||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED ERRATA||QA Contact:||Release Test Team <release-test-team>|
|Version:||6.1||CC:||atodorov, dlehman, ebenes, mbanas, sgrubb, twoerner|
|Fixed In Version:||dracut-004-46.el6||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-05-19 07:54:23 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
|Bug Blocks:||584498, 692515, 846801, 846802|
Description Stephan Mueller 2011-03-28 10:18:33 EDT
Description of problem: (please note that I am not fully sure that this is the fault of dracut-fips - it may also be an issue in anaconda) Using the latest RHEL6.1 alpha ISO from Mar 17 and installing it with fips=1, and adding the dracut-fips package, I cannot boot the system. Note that I installed the system using anaconda kickstart where the boot image was started with fips=1, and a kickstart file where logvol --encrypt is used. When rebooting after successful installation, I get: first there is a mount error (wrong fs type, bad option, bad superblock on ...) - I guess it is the error to mount the root partition dracut: FATAL: FIPS integrity test failed dracut: Refusing to continue dracut: FATAL: FIPS integrity test failed dracut: Refusing to continue Then a kernel panic due to killing init.
Comment 2 Harald Hoyer 2011-03-28 11:06:08 EDT
Is the boot device specified on the kernel command line? "boot=<boot partition>"
Comment 3 Stephan Mueller 2011-03-28 11:16:30 EDT
there is no boot= entry on the kernel command line.
Comment 4 Harald Hoyer 2011-03-28 11:19:50 EDT
does it work, if you add it?
Comment 5 Stephan Mueller 2011-03-28 11:34:14 EDT
(In reply to comment #4) > does it work, if you add it? please scratch my previous remark - I already re-installed my system. I again install it with fips=1 and report back.
Comment 6 Stephan Mueller 2011-03-28 13:20:48 EDT
After re-install with fips=1 and verifying that the same error occurs, the boot= parameter is missing from the kernel command line. After adding boot=/dev/vda1 (/boot is on /dev/vda1), I still get the error. When looking further, it seems that the initramfs tries to mount the root partition which however is a dm_crypt partition. Therefore, it *seems* that the logic to figure out that the root partition is a dm_crypt in the initramfs does not work - note that there is a mount of the /dev/mapper/<UUID> where the UUID points to the dm_crypt-protected partition.
Comment 7 Harald Hoyer 2011-03-28 15:00:37 EDT
(In reply to comment #6) > After re-install with fips=1 and verifying that the same error occurs, the > boot= parameter is missing from the kernel command line. > > After adding boot=/dev/vda1 (/boot is on /dev/vda1), I still get the error. > > When looking further, it seems that the initramfs tries to mount the root > partition which however is a dm_crypt partition. Therefore, it *seems* that the > logic to figure out that the root partition is a dm_crypt in the initramfs does > not work - note that there is a mount of the /dev/mapper/<UUID> where the UUID > points to the dm_crypt-protected partition. can you add "rdinitdebug" to the kernel command line and show me the boot output?
Comment 8 Stephan Mueller 2011-03-28 15:51:44 EDT
Instead of rdinitdebug, I got some other news: If I add boot=/dev/vda1 before the root= parameter, I get the crash as depicted above. If I append boot=/dev/vda1 as the last parameter, it boots. So, is there an order of parameters to be maintained? Why is the boot=... not added by anaconda or any other part of the install system?
Comment 9 Chris Lumens 2011-03-29 10:50:52 EDT
Please attach the bootloader configuration as written by anaconda before any modification to this bug report.
Comment 10 Stephan Mueller 2011-03-29 11:17:36 EDT
This is the command line in menu.lst: kernel /vmlinuz-2.6.32-122.el6.x86_64 ro root=/dev/mapper/luks-6e9bdc63-df7a-43a7-aec9-40462ac37e5a boot=UUID=2ca47455-234f-4ae0-93dd-e682daffe65a rd_LVM_LV=VolGroup01/root rd_LUKS_UUID=luks-6e9bdc63-df7a-43a7-aec9-40462ac37e5a rd_LVM_LV=VolGroup01/LvSwap rd_LUKS_UUID=luks-bbf97b00-74f6-4c7c-bac6-bce8b5d247cd rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=us fips=1 crashkernel=auto audit=1 rhgb quiet Note, audit=1 was added with a kickstart command bootloader --append="audit=1" However, the missing boot= parameter also occurs even without this --append.
Comment 11 Stephan Mueller 2011-03-29 11:20:16 EDT
Oh, I just see that there is a boot= parameter! Hm, but it apparently does not work - see my remark above that the position of the boot= parameter seems to be important too. Note that the UUID in the boot= parameter points to /dev/vda1 - i.e. the correct partition holding /boot.
Comment 12 Harald Hoyer 2011-03-29 19:09:44 EDT
(In reply to comment #11) > Oh, I just see that there is a boot= parameter! Hm, but it apparently does not > work - see my remark above that the position of the boot= parameter seems to be > important too. > > Note that the UUID in the boot= parameter points to /dev/vda1 - i.e. the > correct partition holding /boot. does it work, if you replace "boot=UUID=2ca47455-234f-4ae0-93dd-e682daffe65a" with "boot=/dev/vda1" ?? Which would explain the position problem... "boot=/dev/vda1" would be overwritten by the later "boot=UUID=2ca47455-234f-4ae0-93dd-e682daffe65a"
Comment 13 Stephan Mueller 2011-03-30 03:27:38 EDT
Vhen leaving the boot= parameter at the location where anaconda placed it but replacing the UUID with /dev/vda1, it works (the system boots).
Comment 14 Martin Banas 2011-03-30 08:44:15 EDT
Created attachment 488751 [details] dracut with rdinitdebug Attaching a rdinitdebug log
Comment 16 Martin Banas 2011-03-30 09:14:28 EDT
Hello Stephan, If an installation is started with fips=1, should the package dracut-fips be installed by default? Now the only way how to install it is in kickstart since user can't select it in UI.
Comment 17 Steve Grubb 2011-03-30 09:20:18 EDT
I would say this is desirable. By booting with FIPS=1, the user has indicated they want FIPS compliance.
Comment 19 Stephan Mueller 2011-03-30 09:28:56 EDT
From a CC point of view, it is only a nice to have to ensure that the CC configuration automatically is in FIPS mode. For the FIPS validation, dracut-fips is a must as it ensures the proper integrity checking during boot time.
Comment 20 Stephan Mueller 2011-03-30 09:31:58 EDT
> Now the only way how to install it is in kickstart since user can't select it > in UI. Why would someone boot the install system with fips=1? I guess the only intention is to have the system in FIPS mode after install. Therefore, I would suggest to install dracut-fips unconditionally when fips=1 is given. Note, having a UI where you select the fips mode is highly misleading as this same UI offers the disk encryption. Only if the kernel is booted with fips=1, the disk encryption key is generated with a FIPS-compliant RNG. Therefore, I would suggest not to provide any UI addition for FIPS mode.
Comment 21 Stephan Mueller 2011-03-30 09:33:40 EDT
(In reply to comment #14) > Created attachment 488751 [details] > dracut with rdinitdebug > > Attaching a rdinitdebug log With the log you see that the UUID resolution is flawed as it resolves the root partition and not the boot partition.
Comment 22 Harald Hoyer 2011-03-30 09:50:01 EDT
Comment 24 Martin Banas 2011-03-31 09:17:11 EDT
There's another bug in kernel which prevents this one to be verified: https://bugzilla.redhat.com/show_bug.cgi?id=692515 It seems the .hmac and checksum differs. boot: linux Please wait, loading kernel... Elf64 kernel loaded... Loading ramdisk... ramdisk loaded at 03700000, size: 17878 Kbytes OF stdout device is: /vdevice/vty@30000000 Preparing to boot Linux version 2.6.32-128.el6.ppc64 (email@example.com) (gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP Mon Mar 28 21:49:38 EDT 2011 Max number of cores passed to firmware: 0x0000000000000200 Calling ibm,client-architecture-support... done command line: root=/dev/mapper/vg_ibmjs2205-lv_root ro boot=UUID=c01718b0-d895-4895-9b89-c08283baf3f2 rd_LVM_LV=vg_ibmjs2205/lv_root rd_LVM_LV=vg_ibmjs2205/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us fips=1 console=hvc0 crashkernel=auto rhgb quiet memory layout at init: memory_limit : 0000000000000000 (16 MB aligned) alloc_bottom : 0000000004880000 alloc_top : 0000000008000000 alloc_top_hi : 0000000008000000 rmo_top : 0000000008000000 ram_top : 0000000008000000 found display : /pci@800000020000202/display@1, opening... done instantiating rtas at 0x00000000074e0000... done boot cpu hw idx 0000000000000000 starting cpu hw idx 0000000000000002... done starting cpu hw idx 0000000000000004... done starting cpu hw idx 0000000000000006... done copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x0000000004890000 -> 0x00000000048917fb Device tree struct 0x00000000048a0000 -> 0x00000000048c0000 Calling quiesce... returning from prom_init radeon 0002:00:01.0: Invalid ROM contents radeon 0002:00:01.0: Invalid ROM contents [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM /boot/vmlinuz-2.6.32-128.el6.ppc64: FAILED computed = 6f39b5c725ead894b22fd334b9b349e7c1444d6a705d95a1f1c1655472d744a478d5da5f725287150a5aa45233e59b6ab447714075cf8e4fc88281246dcc7d64 expected = 6c5c405c9031d5dffae0223e4e5567ab31a64b65b83f50b22ace3e1166d3700bddebb20a522b2a52ad08a447bdab6efe4fb5c59bff0688c61adf1f72a92b19bc dracut: FATAL: FIPS integrity test failed dracut: Refusing to continue Kernel panic - not syncing: Attempted to kill init! panic occurred, switching back to text console Rebooting in 180 seconds..
Comment 25 Stephan Mueller 2011-04-04 10:11:03 EDT
fix works for me
Comment 26 Alexander Todorov 2011-04-05 11:02:58 EDT
I performed install with fips=1 and anaconda-13.21.109 from a nightly build. /proc/cmline (grub.conf) after install contains boot=UUID=..... parameter and the system was able to boot into runlevel 3 without any issues. Moving to VERIFIED.
Comment 27 errata-xmlrpc 2011-05-19 07:54:23 EDT
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0523.html