Description of changes

This brings https://github.com/nix-community/lanzaboote UEFI stub in-tree.

Dependents:

• nixos/boot/systemd-boot: add UEFI Secure Boot via lanzaboote #263713

Dependencies:

• Either of:
  • lib.systems.inspect: isEfi → hasEfi rename #263711
  • lib.systems.inspect: deprecate isEfi #264297

Related:

• lanzaboote-tool: init at 0.3.0 #263712
• lib/systems: add aarch64-windows #263714.

Current design

Stub and tool are packaged in the global hierarchy as: lanzaboote-tool and lanzaboote-uefi-stub, no assumption on the system are encoded inside their package respectively.

It is expected to build the UEFI stub using a UEFI system with a UEFI compiler.

The linker is a flavored linker which will propagate adequately the lld Windows-style driver for arguments.

lanzaboote-tool is supposed to be wrapped to know about its lanzaboote-stub, unfortunately, this is impossible to achieve inside of nixpkgs, multiple attempts were proposed to the reviewers in the next section and were all rejected. Therefore, the only solution is to give up on having a wrapped lanzaboote-tool and propose a semi-wrapped lanzaboote-tool and expect the user to understand they have to export the LANZABOOTE_STUB environment variable to know about the stub itself.

This is what we do in the systemd-boot NixOS module ourselves and we expect to work in many cases, either case, author would like to move this PR forward ideally and not concern themselves further with the semi wrapping issue stemming from the impossibility to build a package as a data via cross-compilation inside of nixpkgs, alas.

What has been tried?

• Trivial implementation using nixpkgs reimport inside of pkgs/ hierarchy: NACK because it reimports nixpkgs inside nixpkgs.
• Introduction of a UEFI system example: NACK because there is divergence on the system data, see discussion on MinGW style vs MSVC and GNU-Config as a general.
• Complicated implementation by locally rebooting nixpkgs inside the package definition of the tool to compile the stub using a hacked stdenv: NACK because it's too complicated.
• Complicated implementation by locally rebooting a new package scope called uefiPkgs for cross compilation inside nixpkgs without a direct reimport: NACK because it's too complicated and does not compose well.

Some funny questions

It seems like this PR tries to move to make UEFI a proper target in nixpkgs, but there's already plenty of "data as UEFI binaries" inside of nixpkgs without any cross compilation involved per se:

• EDK2/OVMF firmware
• systemd-boot
• GRUB EFI

Ideally, we should treat the same way as in this PR, I suppose this will be very hard given their build system.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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.05 Release Notes (or backporting 22.11 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.