DeviceTree Support

colemickens commented

2024-06-29 03:47:00 +00:00

(Migrated from github.com)

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:

I don't think I have the bandwidth/energy to try to fix the installer up to support hardware.deviceTree properly
I hacked the installer's grub config to add DEVICETREE lines, set to ${kernelPkg]/${deviceTree.name} which I'm hoping will just work.
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:

Would y'all be open to lanzaboote supporting writing systemd-boot entries with the appropriate device tree option?
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.

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.

👍 1

colemickens commented

2024-07-09 00:09:48 +00:00

(Migrated from github.com)

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.

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 commented

2024-07-09 04:13:21 +00:00

(Migrated from github.com)

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.

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](https://github.com/systemd/systemd/pull/28070) 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.

❤️ 1

colemickens commented

2024-07-16 00:42:27 +00:00

(Migrated from github.com)

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)

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)

kuruczgy commented

2024-08-26 13:09:30 +00:00

(Migrated from github.com)

Until we have TPM support on the X1E the case for using secure boot isn't very strong, but once we have that I might be motivated to have a crack at this, and see if I can get a PoC working.

valpackett commented

2025-06-28 07:08:15 +00:00

(Migrated from github.com)

Until we have TPM support on the X1E the case for using secure boot isn't very strong

Why wouldn't it be? Verification and measurement are almost kinda orthogonal. The TPM can facilitate things like passwordless (or just hardware-bound) FDE, but Secure Boot is what actually verifies the UKI, which can then verify the filesystem even without any FDE at all (dm-verity, fs-verity, IMA/EVM) – see https://github.com/NixOS/nix/issues/4917 – or you can type your FDE password into a verified initrd and then rely on FDE for further runtime, etc.

all the systemd stuff just assumes you have the correct DTB chosen ahead of time, before signing even

Not anymore! 🙃 Since https://github.com/systemd/systemd/pull/34855 the systemd stub supports matching HWIDs to DTBs (basically a mini-dtbloader embedded in each UKI)!

NixOS has also meanwhile gained a stock UKI module based on systemd's ukify, so I think it should be possible to use that, adding boot.uki.settings.UKI.{DeviceTreeAuto,HWIDs} for DTB selection (~~no existing download of the HWID files in JSON format yet: https://github.com/TravMurav/dtbloader/issues/7~~ current JSON file collection), and signing can be added in the same place! It's only the systemd-boot-builder that would need to be extended or replaced to drop the UKIs into the ESP instead of generating configs (and systemd-boot itself should be signed for Secure Boot).

> Until we have TPM support on the X1E the case for using secure boot isn't very strong Why wouldn't it be? Verification and measurement are almost kinda orthogonal. The TPM can facilitate things like passwordless (or just hardware-bound) FDE, but Secure Boot is what actually verifies the UKI, which can then verify the filesystem even without any FDE at all (dm-verity, fs-verity, IMA/EVM) – see https://github.com/NixOS/nix/issues/4917 – or you can type your FDE password into a verified initrd and then rely on FDE for further runtime, etc. > all the systemd stuff just assumes you have the correct DTB chosen ahead of time, before signing even Not anymore! 🙃 Since https://github.com/systemd/systemd/pull/34855 the systemd stub supports matching HWIDs to DTBs (basically a mini-dtbloader embedded in each UKI)! NixOS has also meanwhile gained a [stock UKI module](https://github.com/NixOS/nixpkgs/blob/d0aef5b0a2049479dc5fd4a1a0334ee6a2a1e9b9/nixos/modules/system/boot/uki.nix) based on systemd's `ukify`, so I think it should be possible to use that, adding `boot.uki.settings.UKI.{DeviceTreeAuto,HWIDs}` for DTB selection (~~no existing download of the HWID files in JSON format yet: https://github.com/TravMurav/dtbloader/issues/7~~ [current JSON file collection](https://github.com/anonymix007/systemd-stub)), and signing can be added in the same place! It's only the `systemd-boot-builder` that would need to be extended or replaced to drop the UKIs into the ESP instead of generating configs (and systemd-boot itself should be signed for Secure Boot).

kuruczgy commented

2025-06-28 10:25:52 +00:00

(Migrated from github.com)

Why wouldn't it be?

I guess you are right, I usually think of Secure Boot as something that's easy to turn off for an attacker, but as long as your hardware is reasonably well protected against resetting the UEFI password, I think it should be mostly secure. (We should be on the lookout for any "BIOS reset" jumpers on X1E motherboards though, on my desktop motherboard at least there is just a labeled jumper for this.)

> Why wouldn't it be? I guess you are right, I usually think of Secure Boot as something that's easy to turn off for an attacker, but as long as your hardware is reasonably well protected against resetting the UEFI password, I think it should be mostly secure. (We should be on the lookout for any "BIOS reset" jumpers on X1E motherboards though, on my desktop motherboard at least there is just a labeled jumper for this.)

Rows
Columns

DeviceTree Support #369