Description of problem: The support for FIPS in fedora was missing. I opened bug 805538 to get support in the kernel. While testing the latest build in koji, I found that dracut seems to be causing a problem. When booting I get the following: Loading initial ramdisk /boot/vmlinuz-3.3.0-8.fc16.x86_64: OK FATAL: Module aes_generici not found dracut: FATAL: FIPS integrity test failed dracut: refusing to continue Version-Release number of selected component (if applicable): dracut-013-20.fc16.noarch How reproducible: everytime Steps to Reproduce: 1. see bug 805538 for steps
Turns out that there is an extra 'i' at the end of generic that is causing the problem. After fixing that, it can't find aes-xts. Changing that to just xts works. Also, I don't see gf128mul like the RHEL kernel has, so we should probably add that while we are at it. With those fixes, Fedora boots all the way to the gdm login.
dracut-018-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dracut-018-1.fc17
Package dracut-018-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-018-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-5367/dracut-018-1.fc17 then log in and leave karma (feedback).
This still fails in fips mode for me with aes-ni with: skcipher: Failed to load transform for ecb-aes-aesni: -2 This is with or without adding the "fips" and "fips-aesni" modules via add_dracutmodules+="fips fips-aesni"
dracut-018-12.git20120416.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dracut-018-12.git20120416.fc17
This update behaves the same as before Adding IMA modules to the dracut.conf causes the selinux parts to be dragged in causing failure to find selinux policy because systemd is supposed to do this, I understood from Harald that IMA is now also supposed to be done via systemd and not dracut, so this is to be "expected" though in some sense, I think it would be better to remove these dracut modules from the fedora package if these are never supposed to be used, to avoid user confusion and boot failures when they try to add it at the wrong place in dracut instead of using systemd note fips booting still fails but that's not dracut's fault, as the AES-NI module is not fips allowed, due to lack fo test vectors in the kernel code.
(In reply to comment #6) > This update behaves the same as before > > Adding IMA modules to the dracut.conf causes the selinux parts to be dragged in > causing failure to find selinux policy because systemd is supposed to do this, > > I understood from Harald that IMA is now also supposed to be done via systemd > and not dracut, so this is to be "expected" > > though in some sense, I think it would be better to remove these dracut modules > from the fedora package if these are never supposed to be used, to avoid user > confusion and boot failures when they try to add it at the wrong place in > dracut instead of using systemd right.. will do > > note fips booting still fails but that's not dracut's fault, as the AES-NI > module is not fips allowed, due to lack fo test vectors in the kernel code. ah! good to know!
dracut-018-23.git20120419.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dracut-018-23.git20120419.fc17
dracut-018-23.git20120419.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Reopening the bug. Booting into FIPS mode still fails on the integrity check as reported originally. I'm testing minimal install in a common KVM virt guest on top of F16, using configuration steps [1]: Packages: dracut-018-40.git20120522.fc17.noarch dracut-fips-018-40.git20120522.fc17.noarch kernel-3.4.0-1.fc17 Steps to Reproduce based on [1]: 1. No prelink in minimali install 2. undo and disable prelink othervise 3. yum install dracut-fips 4. dracut -f 5. reboot 6. modify kernel boot params in grub2 menu by appending "fips=1" 7. boot (F10) Result is the reported kernel panic. 1. https://bugzilla.redhat.com/show_bug.cgi?id=805538#c0
Are you setting the boot= kernel parameter, too?
note you also need to specify boot=/dev/vda1 (or whatever your /boot partition is) to boot in fips mode. You will need a kernel patch for AESNI self test passing. but you are right that there is still a bug in dracut with this. I got sidetracked looking into that issue, but will report when i know more.
(In reply to comment #11) > Are you setting the boot= kernel parameter, too? Good point Steve, sorry this has been ommited from the step 6.. With or without it, results are the same. Step 6 should be: 6. modify kernel boot params in grub2 menu by appending "fips=1" and "boot=your-boot-partition" Paul, could you plaease point me to a bugzilla where the AES-NI selt test issue is tracked? Unfortunately I haven't found it in a bugzilla so far. Thanks!
I added it as rhbz#830898
so, what is wrong with dracut?
I can now boot properly in fips mode on f17 with kernel 3.4.0-1 and a patch. For dracut, I needed to remove the module aes-xts in 01fips/module-setup.sh from the _fipsmodules list. It still works with my encrypted root fs and on aesni hardware. So with that change made, this issue is resolved for me
Just to be clear, the issue described in Comment #17 is a kernel problem and no action is required for this one by dracut maintainers. AES-XTS is intended to be in the FIPS Security Policies.
(In reply to comment #18) > Just to be clear, the issue described in Comment #17 is a kernel problem and > no action is required for this one by dracut maintainers. AES-XTS is > intended to be in the FIPS Security Policies. but there currently is no "aes-xts" kernel module to modprobe.... so it does need a dracut change.
OK, that was noted in Comment #1. Changing it to xts fixed the problem for me.
for me, xts was not needed. I removed the entire entry and cryptd/luks still works fine
In reply to Comment #21...you can't remove xts. Any module that we need for fips must be loaded. Not having it there will make it work fine. It just won't do the power-on self test that is required by FIPS. The way that this should be approached is to look at RHEL6, because it passes cert. Then we make Fedora do the same things.
See https://bugzilla.redhat.com/show_bug.cgi?id=831598#c6
Was fixed is F17 stable some time ago as well, I think by this update https://admin.fedoraproject.org/updates/FEDORA-2012-9847/dracut-018-78.git20120622.fc17