On s390x, the `BOOT_IMAGE` karg injected by the bootloader is not a path
to the kernel image, but rather an integer describing the index of the
menu entry selected. Because of the way the s390x bootloader works,
there is no information retained about e.g. the path of the kernel that
was loaded.
This causes issues for the FIPS code which assumes that `BOOT_IMAGE` is
a path to the kernel image to derive the HMAC path. In non-OSTree
systems, this ends up working anyway, because the kernel is located at
the root of the boot partition. In OSTree systems, this is not the
case. However, OSTree systems use BLS configs, and they are named in
reverse order of precedence (i.e. menu ordering). So from the
`BOOT_IMAGE` integer, we can figure out which BLS entry was selected.
Add some code to do just this on s390x. This isn't completely foolproof,
because it presumes that (1) BLS configs were used to populate the
bootloader (and that they were exactly in the same state they currently
are when `zipl` was run), and (2) there are no other menu entries
originating from outside the BLS configs. However, if these assumptions
are wrong we would simply fail the boot, which is currently what is
happening anyway.
See also:
https://github.com/openshift/os/pull/546https://github.com/ibm-s390-linux/s390-tools/issues/78
Tested-by: Muhammad Adeel <muhammad.adeel@ibm.com>
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).
It looks like only the 'fips=1' is really supported and it is working
correctly. So instead of failing on 'fips' not clear way give user
information why we are failing.
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.
When using dracut with --hostonly and --no-hostonly-default-device,
/boot will be inaccessible as dracut will most fs modules unless
specified. But FIPS require /boot to be accessible, and it will try
to mount it on boot. It will fail if corresponding fs module is missing.
For most case /boot will be a simple partition, include the fs module
will be enough for FIPS to mount it. For other cases users have to pass
extra parameters by themselves.
Suggested-by: Kenneth Dsouza <kdsouza@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
Since the kernel doesn't allow using any non-FIPS-compliant crypto
algorithms, it doesn't make sense to install them. Even if they are
installed, tcrypt will not test them anyway.
Tested on Fedora 28 x86_64 by booting with fips=1 (with hand-patched
module-setup.sh).
This patch cleans up the default list of kernel modules in the 01fips
dracut module. All the algorithms that are tested in tcrypt are listed
by their algorithm name so that all the generic implementations and
drivers are picked up automatically based on the module alias.
This drops several unneeded modules and even a bogus one (rot13 -- this
one was obviously copy-pasted from tcrypt.c where it was listed as an
easter egg :).
The patch adds also some algorithms that weren't included in the
original set. It turns out in FIPS mode we only need those algorithms
that are marked as FIPS-allowed in testmgr.c (failure to find a non-FIPS
algorithm is ignored). The non-FIPS algorithms are further removed in a
subsequent patch.
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.
Antonio Alvarez Feijoo