feat: add boot-counting support to lanzaboote #477
No reviewers
Labels
No labels
bug
dependency
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
review-next
security
stub
tool
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lanzaboote/lanzaboote!477
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "r-vdp/rvdp/boot_counting"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
GenerationtoBootJson. 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
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!
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.
@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.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.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.