Add an alternative UKI mode using systemd-stub

linyinfeng commented

2024-06-20 08:37:57 +00:00

(Migrated from github.com)

Currently, Lanzaboote's stub has some features missing compared to systemd-stub, users may want to use some of the missed features with some trade-offs they accept - a large ESP and configurationLimit.

So what about adding an alternative UKI mode using ukify and systemd-stub to provide more choices? Just a suggestion.

POC: https://github.com/linyinfeng/lanzaboote/tree/uki.

Currently, Lanzaboote's stub has some features missing compared to systemd-stub, users may want to use some of the missed features with some trade-offs they accept - a large ESP and `configurationLimit`. So what about adding an alternative UKI mode using `ukify` and `systemd-stub` to provide more choices? Just a suggestion. POC: <https://github.com/linyinfeng/lanzaboote/tree/uki>.

👍 3

stv0g commented

2024-09-29 13:32:45 +00:00

(Migrated from github.com)

Support for multi-profile UKIs has been recently merged into systemd:

https://github.com/systemd/systemd/issues/24539

This should allow us to solve the issue, maybe even get rid of lanzastub completely?
Or are there other reasons to keep it?

Support for multi-profile UKIs has been recently merged into systemd: - https://github.com/systemd/systemd/issues/24539 This should allow us to solve the issue, maybe even get rid of lanzastub completely? Or are there other reasons to keep it?

blitz commented

2024-09-30 18:30:30 +00:00

(Migrated from github.com)

The main reason why the thin stub exists is to avoid gobbling up lots of space per generation on the ESP.

This could (maybe) be achieved by generating one huge multi-profile UKI for all generations. The generations can then share kernels and initrds.

The only downside that I see is that the tool that puts this together needs to be very robust, because if there is an issue then you end up with an unbootable system.

The nice thing would be that it would simplify garbage collecting stuff from the ESP, because we manage only a single file.

The number of generations you can combine into one UKI will be limited on practice to how large a PE file your firmware is willing to load though...

The main reason why the thin stub exists is to avoid gobbling up lots of space per generation on the ESP. This could (maybe) be achieved by generating one huge multi-profile UKI for all generations. The generations can then share kernels and initrds. The only downside that I see is that the tool that puts this together needs to be very robust, because if there is an issue then you end up with an unbootable system. The nice thing would be that it would simplify garbage collecting stuff from the ESP, because we manage only a single file. The number of generations you can combine into one UKI will be limited on practice to how large a PE file your firmware is willing to load though...

stv0g commented

2024-10-01 06:11:42 +00:00

(Migrated from github.com)

I thought more about having 1 multi-profile UKI per kernel.
Additional profiles could then be added for other NixOS generation which either:

Just use a different cmdline section (init entrypoint)
Have different initrd and cmdline sections

This would allow us to still avoid having a single huge UKIs which needs to be rewritten with every new generation.

Downside, would be that this makes the whole generation of UKIs even more complex..

I thought more about having 1 multi-profile UKI per kernel. Additional profiles could then be added for other NixOS generation which either: - Just use a different cmdline section (init entrypoint) - Have different initrd and cmdline sections This would allow us to still avoid having a single huge UKIs which needs to be rewritten with every new generation. Downside, would be that this makes the whole generation of UKIs even more complex..

RaitoBezarius commented

2024-10-01 09:49:54 +00:00

(Migrated from github.com)

I think the design that needs to be implemented is the following one:

We collect all generations, we group by kernel, emit a UKI per kernel with no kernel command line.

We can emit all initrds separately, we emit all command lines separately as systemd addons.

We render a loader.conf that does the mix'n'match for us.

Pre-requisite:

systemd-boot needs to transfer addons to systemd-stub: https://github.com/systemd/systemd/pull/28057 — blocked on an PE metadata section reusable for everyone (which needs to fiddle with ukify)
systemd-boot needs to support initrd addons: https://github.com/systemd/systemd/pull/28070
lanzaboote needs to have a switch to render loader.conf with mix'n'match and needs to now sign: UKI, initrds and command lines.

I don't think multi-profile UKIs work for us yet, but happy to be proven wrong.

Though, because this does not buy us a lot except using systemd-stub and we would still need to write code to support all the rest of the unified sections, I'm not convinced it's worth for the maintainer team to invest a lot of time to support this in lanzaboote. systemd-stub UKI based model is possible via image based mechanisms in NixOS right now.

Happy to see someone send PRs to implement this design, though (or propose a better one).

I think the design that needs to be implemented is the following one: We collect all generations, we group by kernel, emit a UKI per kernel with **no** kernel command line. We can emit all initrds separately, we emit all command lines separately as systemd addons. We render a `loader.conf` that does the mix'n'match for us. Pre-requisite: - systemd-boot needs to transfer addons to systemd-stub: https://github.com/systemd/systemd/pull/28057 — blocked on an PE metadata section reusable for everyone (which needs to fiddle with ukify) - systemd-boot needs to support initrd addons: https://github.com/systemd/systemd/pull/28070 - lanzaboote needs to have a switch to render `loader.conf` with mix'n'match and needs to now sign: UKI, initrds *and* command lines. I don't think multi-profile UKIs work for us yet, but happy to be proven wrong. --- Though, because this does not buy us a lot except using systemd-stub and we would still need to write code to support all the rest of the unified sections, I'm not convinced it's worth for the maintainer team to invest a lot of time to support this in lanzaboote. systemd-stub UKI based model is possible via image based mechanisms in NixOS right now. Happy to see someone send PRs to implement this design, though (or propose a better one).

Rows
Columns

Add an alternative UKI mode using systemd-stub #367