systemd lets stdout go to journal only. Usually, this is desired
behavior to ensure that plymouth does not get disrupted.
However in the 01fips case, the system has to halt when the integrity
check fails to satisfy FIPS requirements. So the user will not be able
to inspect the journal.
As this is special to the fips module, we introduce a fips_info() which
works like info(), but deviates the output to stderr when running with
systemd.
Reference: bsc#1164076
Users might see
"modprobe: FATAL: Module xyz not found in directory"
The output from modprobe is semantically wrong in this case and
confuses users. Keep the warning for debugging purposes, but reduce
the severeness.
It now reads "Module xyz not found in directory"
Reference: bsc#1169997
Instead of carrying the kernel and hmac in the install.img (which takes
up more space) use the vmlinuz installed under /images/pxeboot/ and the
.hmac in the install.img /boot.
This check is triggered by the presence of /run/install/repo/images/pxeboot/vmlinuz
Related: rhbz#1782737
E.g. in RHCOS, the `BOOT_IMAGE` from the cmdline is:
(hd0,gpt1)/ostree/rhcos-e493371e5ee8407889029ec979955a2b86fd7e3cae5a0591b9db1cd248d966e8/vmlinuz-4.18.0-146.el8.x86_64
Which of course is a GRUB thing, not an actual pathname we'll be able to
resolve. In fact, we can simply scrap it off from the variable. Our code
is already able to handle both cases: whether the device refers to a
separate boot partition, or just the root filesystem with a regular
`/boot` directory.
It's already the case the `BOOT_IMAGE_PATH` today, in the non-empty
case, includes a trailing `/`, but let's add it to the path we build
here too to make it more obvious.
That way, the HMAC file can contain a relative path instead of an
absolute one. The issue is that right now the kernel RPM bakes the
`/boot/vmlinuz-${kver}` path into the HMAC file which poses an issue for
rpm-ostree systems (and any other system where the kernel isn't simply
in the top-level `/boot`.
For now, we're hacking around this in rpm-ostree:
https://github.com/coreos/rpm-ostree/pull/1934
Though I'd like to propose the same change in the kernel spec file.
There is a small regression in #343: when handling the 'separate boot
partition' case, we're checking for the kernel image in the wrong
location: `BOOT_IMAGE` is the `/boot`-relative path to the kernel image,
so `/boot/${BOOT_IMAGE_PATH}/${BOOT_IMAGE}` expands to e.g.
`/boot/mysubdir1/mysubdir2/mysubdir1/mysubdir2/vmlinuz...`.
We should be using `BOOT_IMAGE_NAME` here instead (and in fact, the next
if-statement does this correctly, so it might've just been accidentally
left out of #343).
In e54ab383 we moved the fips script to a later pahse of boot, since
the /boot might not be available early on.
The problem is that systemd-cryptsetup* services could be run now
started before the do_fips is executed and need the crypto modules
to decrypted the devices.
So let's split the do_fips and load the module before udev does the
trigger.
8f5c5 broke the case where BOOT_IMAGE is not set at all.
This code should handle following:
1) BOOT_IMAGE not set
2) BOOT_IMAGE set to something unrelated (s390)
3) BOOT_IMAGE=vmlinuz-4.14.7-300.fc27.x86_64
4) BOOT_IMAGE=/vmlinuz-4.14.7-300.fc27.x86_64
5) BOOT_IMAGE=/boot/vmlinuz-4.14.7-300.fc27.x86_64
6) BOOT_IMAGE=subdir/vmlinuz-4.14.7-300.fc27.x86_64
7) BOOT_IMAGE=/subdir/vmlinuz-4.14.7-300.fc27.x86_64
8) BOOT_IMAGE=/boot/subdir/vmlinuz-4.14.7-300.fc27.x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=1415032
Old code did not work for two most common use-cases.
On most machines BOOT_IMAGE is set to something like
/vmlinuz-4.11.3-202.fc25.x86_64. So if we just add prefix "/boot/."
it won't work. Also on machines without /boot on separate partition
BOOT_IMAGE already has the /boot/ prefix (/boot/vmlinuz-3.10.0-799.el7.x86_64).
So let's strip it in such case.
https://bugzilla.redhat.com/show_bug.cgi?id=1415032
On s390 BOOT_IMAGE only denotes the number of the boot record that
was selected in the bootloader and not the path to the kernel image.
Also only bail out, if the kernel hmac checking relies on that path.
If new kernels have modules split out, handle the case, where modules
have to modalias and just install them.
Also add the crypto drivers and names to host_modalias.
otherwise sha512hmac will error out with:
sha512hmac -c /sysroot/boot/.vmlinuz-2.6.32-220.el6.x86_64.hmac
Error opening "/boot/vmlinuz-2.6.32-220.el6.x86_64": No such file or directory.
- also support FIPS on separate LVM partition
- use small settle loop to get /boot
- "set -e" has no effect, if we use "||"
- make fips work with encrypted root and seperate boot
- moved to pre-pivot to support /boot in /
Jóhann B. Guðmundsson