feat: add boot-counting support to lanzaboote #477

Open
r-vdp wants to merge 5 commits from r-vdp/rvdp/boot_counting into master
r-vdp commented 2025-08-26 13:31:12 +00:00 (Migrated from github.com)

There are a couple of preparatory commits, so best to review each commit separately.

Boot counting is controlled with a single option, boot.lanzaboote.bootCounting.initialTries, if this option is set to a non-zero value, new boot entries will be created with a counter added, set to the value specified in that option.
If the option is set to zero, which is also the default, then no boot-counting counters will be added.
Already existing entries will not be modified, so boot counting only applies to new boot entries.

I also bumped the nixpkgs commit in the lock file since we need https://github.com/NixOS/nixpkgs/pull/436893, which adds the userspace services for boot counting.

This PR also fixes https://github.com/DeterminateSystems/bootspec/issues/147 by vendoring the bootspec crate and changing the type of specialisations from Generation to BootJson. This means that we capture the full recursive JSON schema for specialisations, including extensions, while the previous type threw this information away.
This is essential so that users can set separate sort keys for specialisations, to avoid the boot loader falling back to specialisations when a new generation fails to boot. Often specialisations are special cases that we don't want to boot automatically, so they can now be sorted below all normal generations so that if a generation fails to boot, the boot loader will fall back onto the previous generation. See also the newly added test that demonstrates this behaviour.

CC: @RaitoBezarius

There are a couple of preparatory commits, so best to review each commit separately. Boot counting is controlled with a single option, `boot.lanzaboote.bootCounting.initialTries`, if this option is set to a non-zero value, new boot entries will be created with a counter added, set to the value specified in that option. If the option is set to zero, which is also the default, then no boot-counting counters will be added. Already existing entries will not be modified, so boot counting only applies to new boot entries. I also bumped the nixpkgs commit in the lock file since we need https://github.com/NixOS/nixpkgs/pull/436893, which adds the userspace services for boot counting. This PR also fixes https://github.com/DeterminateSystems/bootspec/issues/147 by vendoring the bootspec crate and changing the type of specialisations from `Generation` to `BootJson`. This means that we capture the full recursive JSON schema for specialisations, including extensions, while the previous type threw this information away. This is essential so that users can set separate sort keys for specialisations, to avoid the boot loader falling back to specialisations when a new generation fails to boot. Often specialisations are special cases that we don't want to boot automatically, so they can now be sorted below all normal generations so that if a generation fails to boot, the boot loader will fall back onto the previous generation. See also the newly added test that demonstrates this behaviour. CC: @RaitoBezarius
blitz commented 2025-08-29 20:46:43 +00:00 (Migrated from github.com)

Interesting! It will take me some time to get to this. If there is a way to split this into smaller PRs that would help speed things up!

Interesting! It will take me some time to get to this. If there is a way to split this into smaller PRs that would help speed things up!
r-vdp commented 2025-08-29 22:11:37 +00:00 (Migrated from github.com)

Yeah I can split it, the reason that I didn't is that the earlier commits don't add much value by themselves besides preparing for the boot counting implementation, so I'm not sure that it would make much sense to merge those separately.

But if it would make reviewing easier for you, then I can definitely create individual PRs, more or less corresponding to the commits in this one.

Yeah I can split it, the reason that I didn't is that the earlier commits don't add much value by themselves besides preparing for the boot counting implementation, so I'm not sure that it would make much sense to merge those separately. But if it would make reviewing easier for you, then I can definitely create individual PRs, more or less corresponding to the commits in this one.
r-vdp commented 2025-08-31 12:35:04 +00:00 (Migrated from github.com)

@blitz I split out #479 but I cannot set the base of this branch to a branch in my fork, so the commits still show up here (and boot counting needs that PR).
But so you could review that PR first if you wish, before this one.

@blitz I split out #479 but I cannot set the base of this branch to a branch in my fork, so the commits still show up here (and boot counting needs that PR). But so you could review that PR first if you wish, before this one.
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin r-vdp/rvdp/boot_counting:r-vdp/rvdp/boot_counting
git switch r-vdp/rvdp/boot_counting

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master
git merge --no-ff r-vdp/rvdp/boot_counting
git switch r-vdp/rvdp/boot_counting
git rebase master
git switch master
git merge --ff-only r-vdp/rvdp/boot_counting
git switch r-vdp/rvdp/boot_counting
git rebase master
git switch master
git merge --no-ff r-vdp/rvdp/boot_counting
git switch master
git merge --squash r-vdp/rvdp/boot_counting
git switch master
git merge --ff-only r-vdp/rvdp/boot_counting
git switch master
git merge r-vdp/rvdp/boot_counting
git push origin master
Sign in to join this conversation.
No description provided.