DeviceTree Support

[colemickens]

Hi.

I'm playing with Snapdragon X Elite support, though I don't have applicable hardware for another couple of weeks.

I have an ISO generated with the custom kernel, but I had to commit some sins to try and maybe make the installer Grub (maybe) work:

1. I don't think I have the bandwidth/energy to try to fix the installer up to support hardware.deviceTree properly
2. I hacked the installer's grub config to add DEVICETREE lines, set to ${kernelPkg]/${deviceTree.name} which I'm hoping will just work.
3. But after that, I'll need some bootloader to support generating entries with the appropriate device-tree option set.

To me, lanzaboote is a chance to iterate on this, out-of-tree from nixpkgs, and I'd prefer to use lanzaboote on all of my machines anyway.

From what I can tell, lanzaboote happily compiled for aarch64-linux, but I doubt it has support for device-tree.

Questions:

1. Would y'all be open to lanzaboote supporting writing systemd-boot entries with the appropriate device tree option?
2. Any guidance on how to do this?

I'm naively thinking that the lanzaboote module would just look at config.hardware.deviceTree.{enable,name} and then add the appropriate line to the generation's boot cfg file/entry.

[colemickens]

So, I want to support devicetree better for nixos, outside of extlinux. I don't want to touch grub (perl), I don't want to touch something that feels bespoke and doesn't work for non-iso scenarios (iso-image grub), I don't want to touch systemd-boot (python).

I'd much rather invest in bootspec + lanzaboote:

• I think these need to be updated to be DTB aware:
  • bootspec itself (I think the not yet existing v2 supports extensions? I'd probably just hack it into v1 and make it optional)
  • the PE code
  • the code that measures/canonicalizes/copies the files
• future work:
  • try to make a spin of a nixos iso that leverages lanzaboote instead of a bespoke grub implementation
  • maybe this would actually look like a new nixos module that hand-feeds lanzaboote the "generations" that the installer uses and a target directory to copy to
  • bonus: support cross-arch installations, so that I can build the toplevel somewhere, sign it, and then copy that payload and run a script to install to a /boot on an external drive. This would allow provisioning an aarch64 nixos NVME from an x86_64-linux machine, and I can skip hacking the installer iso.

I realize that using lanzaboote for the ISO is a bit weird, since normally you'd install -> provision -> sign -> load key -> turn on enforcing. But also, it's no worse than the existing setup, and could lead to a reduction of duplication in nixpkgs (if there was appetite for standardizing on lanzaboote).

I could certainly use some advice/guidance/help on this. I'm willing to throw some money at it, too, if there are interested folks.

[ElvishJerricco]

So, I think the issue here is going to be signing the DTB. systemd-boot will not do anything to verify any signature of its devicetree field. Now, with systemd-stub, at least, you can include a .dtb section in the UKI. So we probably want to support that in the lanzaboote stub.

The other issue will be (as we talked briefly about on matrix) choosing the right DTB during boot. Right now this problem has been kind of punted, and all the systemd stuff just assumes you have the correct DTB chosen ahead of time, before signing even. But I think we could use something similar to @RaitoBezarius's work on using addons for .initrd but for the .dtb section. This, of course, depends on there being an agreed upon standard for identifying which device tree is the right one during boot, and there is no such standard.

[colemickens]

For now, I'm going to hack the systemd-boot-builder.py and limp along with that for now. I'm still interested in this, though, if someone wants to shepherd me (probably not for a month or so), or if I can fund someone to do it. Thanks for the thoughts @ElvishJerricco. (Also, I'm fine with punting on the harder part of selecting the DTB from firmware, that seems like a much bigger thing than just some hard-coded .dtb stub support)