nixos/systemd-boot: add option to boot from systemd-stub

[JulienMalka]

Description of changes

This depends on #263442, and will stay in draft until it is merged for that reason.
Enables the possibility to boot from systemd-stub, in preparation for a followup PR allowing encrypted initrd secrets.
Booting from systemd-stub, even if secure boot is not enabled brings some benefits including tpm measurement and forwarding of the encrypted credentials to the initrd.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[JulienMalka]

@ofborg test systemd-boot

[ElvishJerricco]

So, before getting too far with this, we might want to consider how it relates to systemd/systemd#27358, systemd/systemd#28057, and to a lesser extent systemd/systemd#28070.

With these, we can separate the cmdline from the stub-ified kernel+initrd (and with systemd/systemd#28070 we can even separate the initrd) as long as we use Type 1 entries. I am sort of wondering how to ensure that a cmdline addon is only used with the right kernel+initrd, since a given generation should only boot the right ones (I am thinking forward about how to sign this stuff for secure boot). I think it would suffice to just have the initrd contain a file that lists the output paths of the initrd and kernel in the nix store, and to also have those paths in a cmdline parameter. Then initrd just has to check that the contents of that file match the cmdline, and abort otherwise.

[JulienMalka]

@ElvishJerricco I am aware of these systemd-boot PRs. As a systemd-boot maintainer for nixpkgs, here are my 2 cents on what a long-term vision for systemd-boot/secureboot in nixpkgs can be.
Currently, we have the systemd-boot-builder.py backend in nixpkgs and lanzatool out of tree. In the future, when it has feature parity with our current builder and is deemed stable enough, lanzatool will probably replace our current implementation as the systemd-boot backend. If/when the PRs you mentioned are merged and land in the systemd that we have in nixpkgs, lanzaboot will be able to drop lanzastub and instead rely on type 1 boot entries with plugins, which is good because we will be able to use the same stub at upstream.
All these IMHO are long term, a lot of things handled by a lot of different actors still have to work out.
In the meantime, I don't see why we should not be able to continue to bring new interesting features to nixpkgs users. In that specific case, I want to introduce encrypted initrd secrets to nixpkgs. For this, we need to boot from a stub that is able to locate the credentials in the boot partition, and pack them into a CPIO archive to forward them to stage 1. systemd-stub as compatibility for that, lanzastub has compatibility for that. I now want to introduce encrypted initrd secrets to nixpkgs and guard the feature under the condition that you are booting from a stub that support them, but I kinda need to introduce booting from a stub that support them in nixpkgs first, and that is systemd-stub.