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>
78557f05a6