Depends on https://github.com/DeterminateSystems/bootspec/pull/68

This removes our dependency on checking about bootspecs ourselves, etc.

We can now take it easy and rely on DetSys's library.

~Some minor stuff I am not too certain of, c.f. Default trait for SecureBootExtension.~

Also, it enable out-of-tree SecureBoot in unstable NixOS. :)

We currently only embed file names. While we do check whether these files are then signed, an attacker can mix and match any signed kernel and initrd. To prevent this, we now also embed a Blake3 hash of kernel/initrd into lanzaboote.

The upside of this is that the initrd does not have to wrapped into a PE file for signing anymore, because we guarantee its integrity using the signed hash from lanzaboote.

The downside is that blake3 has doubled the size of the lanzaboote binary.

Review commit-by-commit to have less clutter.

The flake was getting hard to work with because it's getting pretty long and was not formatted. I refactored the nix bits:

• Formatted everything with nixpkgs-fmt
• Applied suggestions from statix
• Moved the module (lanzaboote.nix) and the package (uefi-run.nix) into corresponding subdirs in the nix directory
• Moved the tests into a separate file in the nix subdirectory
• Added nixpkgs-fmt and statix to devShell

Review commit by commit

This PR:

• fixes Clippy issues in lanzaboote (where possible),
• switches the build of all Rust components to Crane (Thanks to https://github.com/ipetkov/crane/pull/174 :tada:)
• enables clippy for lanzaboote in nix flake check
• drops the Naersk dependency

This PR will have some trivial merge conflicts with #21. But as they are easy to resolve, we can merge these PRs in any order.

This PR enables setting a configuration limit for lanzatool via the --configuration-limit parameter.

It includes

• Unit tests for the garbage collector.
• Some fixes that I made while debugging (incl. a unit test in esp.rs)
• Infrastructure for integration testing of the lanzatool binary via assert_cmd and an initial test for the GC. Some minor changes needed to be made to the flake to support the new lanzatool integration tests.

It is missing a NixOS integration test because it turns out these are really hard to implement with an out-of-tree module (and even nixpkgs does not contain any tests for the config limit).

I recommend review commit-by-commit.

This PR works towards the green checkmark in GNOME Device Security. For that we need to:

• [ ] Placate fwupdtool security
  • [ ] Make thinklmi export a sane sysfs (see Linux patch)
    • The current patch is wrong. See discussion in: https://bugzilla.kernel.org/show_bug.cgi?id=216460
  • [ ] "Unsupported CPU" on AMD? https://github.com/fwupd/fwupd/issues/5284
• [ ] Enable kernel lockdown
  • [x] Enable the kernel options
  • [ ] Enable lockdown on boot

As we can see in https://bin.hubrecht.ovh/?b376f2a3f8e744c3#8hdQHWaR7zvZCtYikanp1CdTL16z5jgD6UBV6b4SECW4 , when we run nixos-rebuild switch with lanzaboote activated, it deletes almost all directories in /boot/EFI/, but the directory/boot/EFI/loader` is used to store the configuration of the bootloader, so it is erased at each rebuild. This is very annoying as when we use systemd-boot there is no longer a timeout and we cannot choose which generation we want to boot on.

I've tried to remove everything that better belongs in the issue tracker. I've also removed stale information and links. While I was there I also tried to improve the overview information so people have an easier time getting started.

Lanzatool had a couple of avoidable Path to String conversions. These are problematic, because they can easily fail if a user has a messed up way of calling files. :)

All of them happened in order to pass paths as command arguments. In this case, these conversions are avoidable, because Command takes OsString as well. And we can construct OsString from Path without the possibility of failing.

When lanzatool is in the packages attr of the devShell, any compliation error in lanzatool means direnv cannot load the environment anymore. Then LSP support in your editor and even cargo in your shell is missing.

We could simplify our cross compilation story by using flake-parts instead of doing the flake on our own. This would also simplify adding other tools such as https://github.com/cachix/pre-commit-hooks.nix/ .

If you remove a sig of a systemd-bootx64.efi, lanzatool will turn a blind eye and not sign it.

Causing surprising behaviors such as security violation :-((((

This is open for comments, implementation will follow once I have a bit of time.

So we discussed this during the sprint and never got around it properly.

A NixOS user is going to go through these steps in his life:

• disabled SecureBoot
• enabled SecureBoot
• disabled SecureBoot
• enabled SecureBoot

etc.

NixOS has this neat feature about rollbacks, and SecureBoot interferes with it by breaking the unsigned generations.

Note that a generation signed with the wrong key is considered as an unsigned generation here.

To offer maximum flexibility, I want to offer three policies:

• resign: ignore all risks and resign everything, this is particularly dangerous but fine on a development machine, testing machine and people who do not believe they are going to be targeted by Bad Actors™, of course, we do not advise this level of policy for normal operations.
• resign-last-only: resign only the LAST (or current) generation. Assuming a rootkit infecting everything that looks like a kernel, initrd, etc., this will not fix the situation. But, if you build a new generation that you inspect and trust, this can alleviate the problem, then you can have an unsigned generation you can go back in case lanzaboote is broken. We recommend this policy for normal operations.
• ignore: break all old generations (until SB is disabled), this is recommended for more serious operations, combined with appropriate way to trust your derivations at runtime.