set BOOT_IMAGE in bootmap #78

sharkcz · 2019-12-17T09:46:41Z

There are some use cases that rely on having BOOT_IMAGE= set. There is a inconsistency on the s390x platform, because booting from DASD sets it, but booting from virtio disk in KVM does not. When looking at other platforms, then grub2 sets it on x86, aarch64, pseries (ppc).

Please read
https://bugzilla.redhat.com/show_bug.cgi?id=1782026 (the original request)
https://lists.gnu.org/archive/html/qemu-devel/2019-12/msg02999.html (follow up discussion with virt people)
for more information.

borntraeger · 2019-12-17T12:50:48Z

Looking at https://bugzilla.redhat.com/show_bug.cgi?id=1415032 what you actually want it that the zipl program appends "BOOT_IMAGE=<kernel file name after last "/"> for all variants (DASD, SCSI, virtio).
Is that correct?
That would mean that adding "BOOT_IMAGE=<kernel file name after last "/"> when writing the boot records (and not during boot) would actually solve your problem?

Prashanth684 · 2019-12-17T13:17:47Z

As of today on a zVM system, BOOT_IMAGE is a number indicating the selected boot record. For the purpose specified in https://bugzilla.redhat.com/show_bug.cgi?id=1782026, it needs to be the path to the kernel file name. It would be nice to be consistent across all variants to have just one or the other. I would prefer the kernel file name since that is how it is specified for other arches and used in dracut too.

jlebon · 2021-05-13T20:27:50Z

If changing the semantics of BOOT_IMAGE is too late at this point, could we introduce a new e.g. BOOT_IMAGE_PATH kernel argument which is simply the /boot-relative path to the kernel image? For BLS configs at least, this would just mean taking the value of the linux key and converting that to a BOOT_IMAGE_PATH=$value karg.

Prashanth684 · 2021-05-14T00:00:37Z

@jlebon that sounds like a reasonable idea. @sharkcz @borntraeger thoughts? @borntraeger like you mentioned, this new argument would be added when writing the boot records.

xnox · 2021-05-14T17:14:07Z

In UEFI world, we can tell which drive something has booted from and how. Which menu entry. And which files. Upon network boot we normally pass the interface mac address as the command line arg.

So yes, having all that information passed to the kernel would be nice. Aka ccw id of the thing we booted from, which menu number if any, and file path. To know if i booted off 0.0.300 and what menu entry I did there.

Are there any other ways that this information is already exposed by the HMC / z/VM ? anything in /proc or /sys?

stefan-haberland · 2021-05-20T13:52:55Z

Hi,
some information can be obtained from /sys/firmware/ipl/ this is what lsreipl uses as well. Device, ipl_type, loadparm and parm for ccw type IPL for example.

For the zipl BOOT_IMAGE entry there is currently not that much choice to provide different information than the number. The zipl loader does simply not know about the filename for example. It only has the title and the entry number available. And it is not that easy to provide/extent this information because we have only a limited amount of space available for the loader entries where the title is stored.

This could for example be omitted/extended by storing additional information in the bootmap for the entry.
There is an upcoming item to support environment blocks for zipl which I can imagine to be helpful here.

But in addition there is also a limitation in the kernel that only 896 byte of data can be stored for the kernel commandline. All currently used data plus whatever should be added in the future would need to fit in this amount of data. I am aware of customer scenarios where with a large amount of devices this was already a problem.

This could be omitted/extended by storing the commandline to a different location in the kernel.

There might be chances to improve all this in the future but this will take time. I can currently only offer to open items for this and they will be prioritized accordingly.

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]>

jlebon · 2021-06-28T15:46:23Z

OSTree-specific dracut workaround for this in dracutdevs/dracut#1539.

nikita-dubrovskii · 2021-06-30T13:32:25Z

Hi,
@stefan-haberland , could you please say, is it a defined behavior:

zVM, Linux installed on zFCP disk - zipl doesn't add BOOT_IMAGE=N to kernel cmdline

Am i right, that BOOT_IMAGE= is only used with DASD disks ?

stefan-haberland · 2021-07-01T08:42:08Z

Hi,

what I can say is that the "BOOT_IMAGE=N" entry is created by the zipl stage2 loader in the menu code (menu.c: menu() ).
This loader is NOT used for zFCP IPL. So the zipl code can not create this entry.

I can not say if the firmware loader, that is used for zFCP, ever created this entry.

nikita-dubrovskii · 2021-07-01T08:47:26Z

Hi,

what I can say is that the "BOOT_IMAGE=N" entry is created by the zipl stage2 loader in the menu code (menu.c: menu() ).
This loader is NOT used for zFCP IPL. So the zipl code can not create this entry.

I can not say if the firmware loader, that is used for zFCP, ever created this entry.

Yep, i saw that code. But how do you think - should zipl also add BOOT_IMAGE on zfcp?

stefan-haberland · 2021-07-01T10:37:11Z

AFAIK this was never intended.

But there are plans to change the BOOT_IMAGE= number to the actual file name and I think it makes sense that this should look identical across all IPL methods afterwards.

jlebon · 2021-07-05T19:36:00Z

But there are plans to change the BOOT_IMAGE= number to the actual file name and I think it makes sense that this should look identical across all IPL methods afterwards.

This sounds great! We just need to make sure we revert dracutdevs/dracut#1539 once that happens.

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]>

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> Resolves: rhbz#2007586

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> (cherry picked from commit 78557f0) Resolves: #2050567

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> Resolves: rhbz#2007586

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> Resolves: rhbz#2050567

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. Refactored to enhance readability. See also: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> Resolves: rhbz#2050567

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> Resolves: rhbz#2050567

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: openshift/os#546 ibm-s390-linux/s390-tools#78 Tested-by: Muhammad Adeel <[email protected]> Resolves: rhbz#2007586

hoeppnerj assigned stefan-haberland Feb 26, 2020

nikita-dubrovskii mentioned this issue May 6, 2021

overlay.d: s390x: add to ramdisk missing zipl openshift/os#546

Merged

jlebon mentioned this issue Jun 17, 2021

fix(fips): handle s390x OSTree systems dracutdevs/dracut#1539

Merged

pvalena mentioned this issue Feb 15, 2022

(#2050567) fix(fips): handle s390x OSTree systems redhat-plumbers/dracut-rhel9#28

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

set BOOT_IMAGE in bootmap #78

set BOOT_IMAGE in bootmap #78

sharkcz commented Dec 17, 2019

borntraeger commented Dec 17, 2019

Prashanth684 commented Dec 17, 2019

jlebon commented May 13, 2021

Prashanth684 commented May 14, 2021

xnox commented May 14, 2021

stefan-haberland commented May 20, 2021

jlebon commented Jun 28, 2021

nikita-dubrovskii commented Jun 30, 2021 •

edited

Loading

stefan-haberland commented Jul 1, 2021 •

edited

Loading

nikita-dubrovskii commented Jul 1, 2021

stefan-haberland commented Jul 1, 2021

jlebon commented Jul 5, 2021

set BOOT_IMAGE in bootmap #78

set BOOT_IMAGE in bootmap #78

Comments

sharkcz commented Dec 17, 2019

borntraeger commented Dec 17, 2019

Prashanth684 commented Dec 17, 2019

jlebon commented May 13, 2021

Prashanth684 commented May 14, 2021

xnox commented May 14, 2021

stefan-haberland commented May 20, 2021

jlebon commented Jun 28, 2021

nikita-dubrovskii commented Jun 30, 2021 • edited Loading

stefan-haberland commented Jul 1, 2021 • edited Loading

nikita-dubrovskii commented Jul 1, 2021

stefan-haberland commented Jul 1, 2021

jlebon commented Jul 5, 2021

nikita-dubrovskii commented Jun 30, 2021 •

edited

Loading

stefan-haberland commented Jul 1, 2021 •

edited

Loading