systemd

mirror of https://github.com/systemd/systemd.git synced 2025-03-21 02:50:18 +03:00

Go to file

Lennart Poettering a632d8dd9f stub: add ability to place multiple alternative PE sections of a specific type in the same UKI ("Multi-Profile UKIs")

This adds a ability to add alternative sections of a specific type in
the same UKI. The primary usecase is for supporting multiple different
kernel cmdlines that are baked into a UKI.

The mechanism is relatively simple (I think), in order to make it robust.

1. A new PE section ".profile" is introduced, that is a lot like
   ".osrel", but contains information about a specific "profile" to
   boot. The ".profile" section can appear multiple times in the same
   PE, and acts as delimiter indicating where a new profile starts.
   Everything before the first ".profile" is called the "base profile",
   and is shared among all other profiles, which can then override or
   add addition PE sections on top.

2. An UKI's command line can be prefixed with an argument such as "@0" or
   "@1" or "@2" which indicates the "profile" to boot. If no argument is
   specified the default is profile 0. Also, a UKI that lacks any
   .profile section is treated like one with only a profile 0, but with
   no data in that profile section.

3. The stub will first search for its usual set of PE sections
   (hereafter called "base sections"), and stop at the first .profile PE
   section if any. It will then find the .profile matching the selected
   profile by its index, and any sections found as part of that profile
   on top of the base sections.

And that's already it.

Example: let's say a distro wants to provide a single UKI that can be
invoked in one of three ways:

1. The regular profile that just boots the system
2. A profile that boots into storagetm
3. A profile that initiates factory reset and reboots.

For this it would define a classic UKI with sections .linux, .initrd,
.cmdline, and whatever else it needs. The .cmdline section would contain
the kernel command line for the regular profile.

It would then insert one ".profile" section, with a contents like the
following:

    ID=regular

This is the profile for profile 0. It would immediately afterwards add
another ".profile" section:

    ID=storagetm
    TITLE=Boot into Storage Target Mode

This would then followed with a .cmdline section that is just like the
basic one, but with "rd.systemd.unit=storage-target-mode.target"
suffixed. Then, another .profile section would be added:

    ID=factory-reset
    TITLE=Factory Reset

Which is then followed by one last PE section: a .cmdline one with
"systemd.unit=factory-reset.target" suffixed to te regular command line.

i.e. expressed in tabular form the above would be:

    The base profile:
          .linux
          .initrd
          .cmdline
          .osrel
    The regular boot profile:
          .profile
    The storagetm profile:
          .profile
          .cmdline
    The factory reset profile:
          .profile
          .cmdline

You might wonder why the first .cmdline in the list above is placed in
the base profile rather than in the regular boot profile, given that it
is overriden in all other profiles anyway. And you are right. The only
reason I'd place it in the base profile is that it makes the UKI more
nicely extensible if later profiles are added that want to replace
something else instead of the .cmdline, for example .ucode or so. But it
really doesn't matter much.

While the primary usecase is of course multiple alternative command
lines, the concept is more powerful than that: for various usecases it
might be valuable to offer multiple choices of devicetree, ucode or
initrds.

The .profile contents is also passed to the invoked kernel as a file in
/.extra/profile (via a synthetic initrd). Thus, this functionality can
even be useful without overriding any section at all, simply by means of
reading that file from userspace.

Design choices:

1. On purposes I used a special command line marker (i.e. the "@" thing,
   which maybe we should call the "profile selector"), that doesn't look
   like a regular kernel command line option.  This is because this is
   really not a regular kernel command line option – we process it in
   the stub, then remove it as prefix, and measure the unprefixed
   command line only after that. The kernel will not see the profile
   selector either. I think these special semantics are best
   communicated by making it look substantially different from regular
   options.

2. This moves around measurements a bit. Previously we measured our UKI
   sections right after finding them. Now we first parse the profile
   number from the command line, then search for the profile's sections,
   and only then measure the sections we actually end up using for this
   profile. I think that this logic makes most sense: measure what we
   are using, not what we are overriding. Or in other words, if you boot
   profile @3, then we'll measure .cmdline (assuming it exists) of
   profile 3, and *not* measure .cmdline of the base profile. Also note
   that if the user passes in a custom kernel command line via command
   line arguments we'll strip off the profile selector (i.e. the initial
   "@X" thing) before we pass it on.

3. The .profile stuff is supposed to be generic and extensible. For
   example we could use it in future to mark "dangerous" options such as
   factory reset, so that boot menus can ask for confirmation before
   booting into it. Or we could introduce match expressions against
   SMBIOS or other system identifiers, to filter out profiles on
   specific hw.

Note btw, that PE allows defining multiple sections that point to the
same offsets in the file. This allows sharing payload under different
names. For example, if profile @4 and @7 shall carry the same .ucode
section, they can define .ucode in each profile and then make it point to
the same offset.

Also note that that one can even "mask" a base section in a profile, by
inserting an empty section. For example, if the base .dtb section should
not be used for profile @4, then add a section .dtb right after the
fourth .profile with a zero size to the UKI, and you will get your wish
fulfilled.

This code only contains changes to sd-stub. A follow-up commit will
teach sd-boot to also find this profile PE sections to synthesize
additional menu entries from a single UKI.

A later commit will add support for gnerating this via ukify.

Fixes: #24539

2024-09-10 06:49:08 +02:00

.clusterfuzzlite

ci: unpin CFLite

2022-04-26 09:13:57 +00:00

.github

build(deps): bump softprops/action-gh-release from 2.0.5 to 2.0.8

2024-09-04 01:25:17 +02:00

.semaphore

semaphore: use variable for Salsa repo URL

2024-05-20 13:14:50 +01:00

catalog

2024-06-24 22:29:38 +02:00