-
Notifications
You must be signed in to change notification settings - Fork 21
Unified Kernel Image #63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
IIRC systemd has some proposals for that? I do not remember the details but was something about storing the cmdline as an external file |
Indeed, I can use addons files to override the cmdline. |
Can the UKI be signed with and empty .cmdline PE section? If that is the case, the cmdline from the addon can be generated locally and delegated to the measure boot process instead of the secure boot one.
How can this work? the cmdline requires local information (root UUID, subvol path with the subvol number, etc) |
root UUID is done by the Discoverable Partitions Specifications, when no CMDLINE has been provided, the tool developed by systemd and present in systemd-stub (stub of the UKI), systemd-gpt-auto-generator, automatically discovers the root partition (https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html) |
|
Ah right! There can be some objections to root uuid auto-discovering in the context of multiple OS installations. But still curious about the rootflag=subvol= parameter[1], the combination of initrd + kernel is only valid for a subset of snapshots (and is the cmdline the one that links them). Do you think that there is a solution for this too? [1] https://github.com/openSUSE/sdbootutil/blob/main/ARCHITECTURE.md#introducing-snapshots |
Yes you are right, this methods is not adapted for multiple OS, or you should to have as UKI as root fs, but that is not something we may want :)
Unfortunately, I do not have any ideas yet about the rootflags parameter.. BTW there is no more combination Kernel+Initrd with the UKI as both are included in the one file. To provide the subvol info, I don't know how the bootloader could pass the information (because the bootloader already know the snapshots number as it is specified into the loader conf file in the Version parameter) to the UKI. I need to study more how snapshots process is done during the boot time |
Yes sorry. My comment was in the direction that one UKI will be only valid for a subset of snapshots, not for all of them, and we need to map this somehow (currently is done by the cmdline)
Do you mean in the It is my understanding that when UKIs are used the sd-boot menu entry is autogenerated from the available UKIs, so the mapping issue is still a question for me in the UKI case: how the user can select to boot one UKI in one specific subvolume, and be sure that this selection is valid. I was expecting that for an UKI solution using snapshots we should need to generate locally the cmdline for an UKI (so we can inspect inside the snapshots the kernels that are valid for it), maybe do some changes in sd-boot to render the combinations of "UKI x addons", and use measured boot instead of secure boot. I think we should work on a more complete design proposal before evaluating this PR, tho. [1] https://www.freedesktop.org/software/systemd/man/latest/loader.conf.html |
I mean Version from the loader conf file:
Yes, menu-entries are automatically generated if UKIs are put in
I agree with you, I will investigate deeper in UKI solution using snapshots :) |
Ah ... I cannot find it ... neither in the documentation nor in my systemd.
Indeed ... like a chain load. I like this idea. |
|
In general I'm ok with adding uki support to sdbootutil. We need to avoid the code duplication with |
Could be good to give a try for a first start yes.
I found this discussion from systemd project, and talk about snapshots begins here : systemd/systemd#24539 (comment) maybe it is the PR you refereed for ? |
|
missed the question part. yes that is the discussion |
- add 'add-uki' and 'remove-uki' command to add or remove an entries using UKI. Signed-off-by: Valentin Lefebvre <[email protected]>
| reset_rollback | ||
| # This action will require to update the PCR predictions | ||
| update_predictions=1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way to calculate predictions will change too, right?
| { | ||
| local subvol="$1" | ||
| local kernel_version="$2" # Same as kernel version | ||
| if [ "$image" = "vmlinuz" ] || [ "$image" = "Image" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mixing tabs and spaces, I added .dir-locals.el for emacs, but you can add another for your editor. I used the one from systemd as an example
| fi | ||
| calc_chksum "$src" | ||
| local dst="/$entry_token/$kernel_version/uki-$chksum" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the hash is to reuse kernel and initrds, do you think that this will be useful for ukis too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure yet but probably not. There is a concept with "extensions", others efi binaries that can be load with the UKI to extend his initrd. In that way, we will have the same structur of kernel+initrd, so the hash could be useful in that case. I need to think about that
| snapshot="${snapshot%/*}" | ||
| local id="$entry_token-uki-$kernel_version-$snapshot.conf" | ||
| run_command_output bootctl unlink "$id" | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is mostly the same code than remove_kernel (missing the prediction stuff), so I am wondering if would make sense to unify {add,remove}_kernel with {add,remove}_uki.
I am not sure that makes total sense, tho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It clearly makes sense to merge $command_kernel with $command_uki, and maybe rename the functions into $command_image.
First goal was to introduce the uki process, that why I split it in these new functions
sdbootutil
Outdated
| aa64) image=Image ;; | ||
| *) err "Unsupported architecture $firmware_arch" ;; | ||
| esac | ||
| if [ -z "$image" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unwanted sorry
Signed-off-by: Valentin Lefebvre <[email protected]>
|
A UKI can now contain multiple profiles, allowing to configure multiple, separate command lines. |
Profile feature is great to have multiple entries for the same UKI but with different command line. However, if I well understand profiles, these sections need to be included into the efi binary, for each new snapshot created, a called to ukify is needed and the efi binary will be regenerated, where in the vendor POV we signed the binary, it is not feasible. However, as you suggested into the linked discussion, a multi-profiles with addons would works for snapshots. It will be closed of what I am testing with UKI and snapshots. I have wrote a short documentation on it : https://github.com/keentux/unified-kernel-image-tool/blob/main/docs/unified-kernel-image.md#v---snapshots |
|
@keentux |
|
Hi @TobiPeterG , Happy to see there are some interests of UKIs on openSUSE. :) Indeed, there are some packages in Factory, available for Tumbleweed:
When installing the uki package it will automatically add a bootloader entry depending if you used grub2 or sdboot. I will recommend to not install yet the uki as I am working of an update that will improve the way bootloader entries are created. It is done by the uki-tool and the release should start asap. You can find more documentation about static-initrd and uki here: https://en.opensuse.org/SDB:Static_Initrd_and_Unified_Kernel_Image About this PullRequest status: I am working on the PR on systemd which I based my POC on to manage snapshots in openSUSE with the UKI, because with the new systemd version, my POC is broken and requires some changes. I hope this provides some insight into the status of the UKI. Please feel free to contact me if you need any information or assistance. 😁 |
Thank you very much for this detailed report. :) I would love to help with snapshot support. If you don't want/need help on that side for now, I would also love to work on the initrd and signing side. We need a way to add the modules the user wants/needs as addons to the base initrd. Do you know if dracut supports creating the addons? |
Yes, it is the PR I refereed,I will soon create a new one which is based on the latest systemd commits, that's why I didn't mention it ;)
Your help would be greatly appreciated, thank you very much for your offer. In order not to burden this discussion with sdbootutil, I created a thread here: val4oss/unified-kernel-image-tool#1
I also created another thread for you that explains how the signing process is done for ukis/initrd/uki-companions |
Goal
The aim of this PR, is to open discussion about the UKI feature for the sdbootutil tool.
Implementation
/usr/lib/modules/$(uname)/<version format specification>.efias described at https://uapi-group.org/specifications/specs/unified_kernel_image/#distribution-built-ukis-installed-by-package-managers. I used the argument--imageto identified the uki name.Corrections
Notes
Tests
Tested on Tumbleweed booting with sd-boot.