I just finished reading the nmbl manifesto. I think the manifesto itself is kinda crap. I slightly agree with the switch_root part, but if you’re going to use KExec, just use Petitboot. It’s probably easier to patch stuff for x86_64 SecureBoot and TPM stuff anyway.
However, I don’t understand what they mean by UKI and how that’s handled. I only understand that it’s a bundle of kernel image, initramfs, cmdline and efistub.
https://www.reddit.com/r/Gentoo/comments/1e1ikge/will_nmbl_be_its_own_package/
I want to see what the gentoo people will have to say about it on their own forums. Just like the post on r*ddit, it looks like nmbl is more like “laab” (linux-as-a-bootloader) and is somewhere in the middle between systemd-boot and something like grub or syslinux (or petitboot).
I must agree that, despite my obsession for petitboot, I don’t like that it’s using an old linux kernel that never changes. I know it’s a very minimal one, more akin to embedded systems (in order to even fit on the SPI flash of most SBCs), only containing FS and networking drivers. You could theoretically build your own petitboot bundle with a newer kernel, but then you’re back to square 1 that the nmbl folks complain about grub: having to maintain the bootloader separately from the kernel you’re running.
Technically, once a kernel has been compiled for a board, you technically never need to update it ever again (particularly if it’s minimal), which is kinda the petitboot de facto behavior, at least as handled by hardkernel / odroid folks.
For nmbl, I don’t want to be too harsh, but seems more like a circus disguised as security. Just look at Gentoo’s SecureBoot wiki entries.
https://wiki.gentoo.org/wiki/Secure_Boot
https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki’s_EFI_Install_Guide/Configuring_Secure_Boot
You literally boot your system without a shim layer. And because Gentoo doesn’t have a need for a initramfs (if you compile the drivers inside the kernel, instead of using kmods), you can literally boot just your signed kernel (you can do this on other distros too, but gentoo makes it easy). Of course, you can load your initramfs first, then firmware modules, then kernel and still have them signed (just that removing the middle-man, the initramfs, makes this a shorter boot path).
And obviously, the place where nmbl will be utilized the most is x86_64 and select ARM platforms that have UEFI. Why mention this? Because UEFI has its own boot options to select your payload. If you’re really that concerned about your system’s security, sign your kernel and boot straight into it from UEFI. You also have options to select the older signed kernel in the the uefi boot menu, if your main / latest one fails.
Instead, nmbl allows you to have only 1 entry in the uefi boot settings, itself, then it selects the signed UKI to boot into, adding another layer to the boot process, compared to direct-booting the kernel as an efi payload.
Now, I’m not saying this is inherently insecure. If the implementation is right, it should be fine and I hope they succeed (despite my pessimism around it).
I don’t exactly understand their goals though. If security is a user’s goal, they should follow the gentoo wiki, maybe implement it on their own system (shouldn’t be that difficult). So, a security-minded individual would want to remove the bootloader layer. So what’s nmbl’s purpose?
I’m more worried about lower-level firmware. All UEFI you’re getting on x86_64 are absolutely proprietary (AMI, Phoenix etc.). Projects like u-boot and coreboot (particularly the libreboot fork) that replace the whole firmware stack are more important. But because of the work involved, you need a custom firmware for each board, unlike a generic bootloader binary.
On odroid boards, petitboot does what u-boot does on most other boards: the CPU itself loads the payload directly, which acts as the “firmware” of the device (enumerating and initializing devices, etc.). I don’t think you can do something like this with nmbl (except if you go the kexec method, which again, is what petitboot does). You’d need petitboot or u-boot (or the lower / minimal / part 1 of u-boot) to load up nmbl, which then loads your OS. But at that point, just use u-boot / petitboot. That’s also one of the criticism of coreboot on aarch64 (you need u-boot to load coreboot) and of u-boot on x86 (you need coreboot or something else to load u-boot).
nmbl… I’ll wait to see how it evolves, before I make any other judgements about it.