Skip to content
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

Follow up muti-profile uki #3073

Open
Tracked by #2990
Itxaka opened this issue Dec 11, 2024 · 0 comments
Open
Tracked by #2990

Follow up muti-profile uki #3073

Itxaka opened this issue Dec 11, 2024 · 0 comments
Labels
enhancement New feature or request triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed

Comments

@Itxaka
Copy link
Member

Itxaka commented Dec 11, 2024

systemd-boot 257 with support for multi-profile efi files has been released https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md#multi-profile-ukis

mutliple profiles on a efi files means that an efi file can have different .profile sections and inside those .profile sections they can override the main efi sections, like .cmdline or even things like .kernel or .dbt

Image

This efi file would produce 3 different entries on the systemd-boot menu, but from a single efi file.
Choosing the entry, would override the main profile with whatever sections are added after it
In this case only the cmdline is override, but supposedly you can override all sections.

.linux
.initrd
.cmdline
.profile  <- this is the main profile, or profile 0 and uses the sections before it.
.profile <- this would be the second profile or profile 1, uses the base sections from profile 0 and overrides those base sections with whatever sections we add after it, stops at either the end of the efi fi its the last profile or the next .profile section
.kernel <- yes, you can override the kernel
.cmdline
.profile <- here the next profile starts. Again it uses the base sections from profile 0 and overrides with whatever is on its own section

This means that we can use it to provide different cmdlines with a single efi file, which would remove some complexity from our uki pipeline

  • recovery and statereset could be merged into a single efi file, with different cmdlines
  • adding debug to an entry will not result in 2 different efi files, just single one with 2 different profiles
  • extra-cmdline artifacts can be added as a profile to the entries (active,passive,recovery) without duplication
  • upgrades for extra-cmdlines deal with less files
  • for SpectroCloud, they would not need to add that many efi files, just a single one with multiple profiles

Very important, our tool go-ukify doesnt have support for creating this types of uki files, although it seems simple to implement as we are just reusing other sections and adding a new .profile section that can be repeated

In any case, as Auroraboot is now based of Fedora, we can always install the latest ukify version from systemd directly, as it has the required deps already in the system (before, leap did not have some of the required deps for a newer ukify version)

Note that if the PCR signature mechanism described above is used it is recommended to include a separate .pcrsig PE section in each profile matching precisely the sections that apply to that profile (i.e. the combination of the profile's own sections and those of the base section).
@Itxaka Itxaka added bug Something isn't working triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed labels Dec 11, 2024
@Itxaka Itxaka moved this to Todo 🖊 in 🧙Issue tracking board Dec 11, 2024
@Itxaka Itxaka added enhancement New feature or request and removed bug Something isn't working labels Dec 11, 2024
@mudler mudler mentioned this issue Nov 11, 2024
42 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage Add this label to issues that should be triaged and prioretized in the next planning call unconfirmed
Projects
Status: Todo 🖊
Development

No branches or pull requests

1 participant