Nmbl: we don’t need a bootloader

Let’s get rid of established piece of software and rewrite it!

Redhat’s quality employee has written a blog post outlining booting with the OSes Linux kernel instead of Grub.
Why? Because Grub is portrayed as insecure and bloated.

My take and discussion starter

Why do I need yet another bootloader? Weren’t there a lot back and forth discussion between the use of Grub and Lilo back in the day? I don’t see Lilo mentioned nowadays. Did Grub win? Is it really that insecure? As a filthy Linux casual I don’t really get it - I’m perfectly fine booting with Grub. Will the new way shave off a few seconds from the boot process? Maybe, but booting is fast enough already.
Interested in your take @ThatGuyB @PhaseLockedLoop

Links

3 Likes

Technically, EFISTUB booting has been around for at least a decade and is pretty tried and tested, but only works directly with kernels installed locally on a FAT32 (EFI) partition. It’s not new, and if you want slightly faster boot times that or systemd-boot (which was originally a separate simplified bootloader project called gummiboot) is the way to go. I’m pretty sure I have not used GRUB for my desktop systems for almost as long, too.

nmbl appears to be based on the same technology with the intention of supporting network boot and some other stuff. For a casual Linux user it sounds kind of unnecessary unless there’s a particular userspace feature you need that doesn’t just work when directly booting the kernel from EFI.

Anyway, yes, for most of us, we don’t need a bootloader. :melting_face:

For further reference: EFISTUB - ArchWiki

6 Likes

-Is Grub insecure?
If an attacker has physical access, absolutely.
If an attacker has physical access you have already lost.

Grub is also invaluable for chain-booting, unlocking encrypted OS drives, and troubleshooting.

Does Grub hold alot of legacy code to support ridiculously old and obscure hardware?
Absolutely, but there are 2 Linux base camps:

  1. My old toaster needs linux - ALL the hardware support ALL the time

  2. Fuck Windows / MacOS - if I want to dd /dev/sda, I should be able to

There should be an optional version of GRUB supporting the latest 4 gens of CPU from each major player as MacOS, Windows, & Android does.

Default to the big honker that just works and make an optional more secure version that does not support IDE boot.

Your main adversary is lazy Linux users resistant to change as it risks losing a devoted user base.

3 Likes

^^^^

If their solution covers the majority features of grub has (and allows the user to manually select a insecure configuration) while being secure on default, I don’t mind.

I’m not a fan of the major distros hamfisted wayland without the establishing the proper xorg translation/migration paths.

2 Likes

The issue is much deeper than simply making a bootloader

Now I DON’T like poettering but having an intelligent requires reading lots of perspectives

You should read this and understand why I want UKIs and I want a bootloader the supports actually securely booting linux. Not the joke that is all current projects.

Nmbl is taking this approach and I approve

4 Likes

Grub is built on a fundamentally flawed concept of the secure boot chain. It doesnt actually verify every step in the boot chain and actively warn you when there is tampering.

The kernel has to and by then its too late. There are ways to mitigate what someone can do with physical access but the trade off is convenience and also simplicity.

Soft Disagree

People repeat the physical access statement partially because its correct in some was but also because its what everyone popularly learned

Grub should have attempted what nmbl is attempting eons ago but instead chose the SHIM route. Which is stupid and a hack. Insecure options are NOT the freedom solutions people think they are claiming it is.

Also TPM has some flaws too. Its bus is unencrypted unironically so YES systems are still vulnerable to physical attacks with TPM thats on the CPU. That said there are open TPMs that are starting to come around and develop and a lot of mobos support alternate TPM or discrete TPM devices.

If we want a secure linux world particularly one that may provide some peace of mind if a system is tampered with like i.e wiping the device after a certain amount of tampering or if the TPM is tampered with then this statement has to be thrown out the window

You should be permitted a less secure option like instead of enforce… Log only… You should not be permitted to continue to be insecure all the time. Some sacrifices and changes must be made at some point to meet the future security needs and considering physical access can now be done rather swiftly with small easy to conceal devices without even stealing the device itself; then yes we have to make a sacrifice of a weee bit of freedom in terms of security configurations. But thats for this project. You are of course free to use howevee boot method you like and if a distro stops supporting it you dont have to use that distro

The best part of linux though is you dont have to use it and you dont need to use everyones projects so if you dont like it nor care then dont worry about it. Im sure grub will be around for a long time. No need to suggest or discourage a project because it doesnt fit into what you want for your system. Again thats the beautiful thing about Linux freedom

3 Likes

I’ll give it a read later, but I’m sure I’m going to agree with it, if PLL already gave his seal of approval. We need more competition in the bootloader space and some people already know I’m a fanboy of petitboot.

But I’m coming from a different perspective.

Not really my point security rant.

I couldn’t give 2 flying rats about secure-boot. If I want secure-boot, I install /boot on a microSD card that I always keep with me and have my rootfs encrypted. The firmware on my devices are way more susceptible to getting hacked (e.g. see all the UEFI malware installed on the motherboard via M$ Windows - I’m not running windows, but the same kind of hack is technically possible on linux using something like fwup if someone gains root access to your device - but if someone has that, you’re in bigger trouble anyway, unlike on windows where there’s workarounds).

Attacks to your bootloader over the internet are harder to pull off. Sure, someone might be able to do a supply-chain attack on you and sell you a motherboard or PC with a bugged firmware that does shady stuff. But that’s kinda unlikely on a large-scale - if you’re not already a targeted individual, you’re probably ok.

With a mal-firmware, your bootloader could be tricked into loading arbitrary code, which PLL seems to be worried about. Instead of loading your initramfs, kernel and if applicable, dtb files, it might load something else (although you’d probably be able to notice it - and since motherboard ROM are generally not that large, I doubt a full kernel would even fit there). However, the malicious firmware should be able to write a quick shell script on your main drive, or even in a tmpfs and point your bootloader to load that arbitrary code (something like init=tmpfs/runme.sh which enables, idk, a keylogger for when you slap in your decryption key and then initializes your system).

And the thing is, PXE booting doesn’t really solve this either. You could be booting from a remote server that you fully trust, but the firmware on the mobo could still possibly mess with it (although that’s kinda harder to believe, I doubt someone would even be thinking you’d be booting via PXE, unless, again, you’re a targeted individual and the mal-firmware was designed to inject code in your pxe boot sequence instead - but again, you’re working with a limited storage in ROM, just how small can this very dangerous malware be?).

GRUB itself is just garbage sometimes. I literally had a bug on my ThinkPenguin 4-bay NAS in which GRUB, no matter the OS (debian 11, debian 12, proxmox 8 and void), when there was no keyboard plugged in, grub booted into either the 4th entry (in proxmox it was memtest), or if it didn’t have that many, just wildly scrolled through all the boot entries and didn’t boot any of them. Plug a keyboard in and grub now just work. WTF?! And don’t think this is just a ThinkPenguin problem, because the motherboard inside it is a generic MSI H510I-PRO. It could happen to literally anyone else. I’ve discovered online that I wasn’t the only one affected and I haven’t found any fix (the workaround is to always have a kb plugged in, which is dumb for a headless server).

I slapped gummiboot on proxmox (systemd-boot) and removed GRUB and, surprise, surprise, no issues when booting headless without a keyboard. My threadripper system is running rEFInd (which kinda sucks, but I knew no better option back then, so I’m not changing it, although I could pretty easily). My PC runs gummiboot-efistub (not even on systemd) and ZFS-Boot-Menu (I’ve got an encrypted rootfs).

My single board computers run petitboot if I can, otherwise u-boot. At this point I’m so frustrated with grub, that I’ll go through whatever I can to not use it if I can. I might allow it in a VM, where I know it’ll always behave consistently (the virtual devices help it), but on bare-metal, oh no, no, no, no, no.

Just like many of my other takes, if it works for you, then don’t change it. My (really bad) experience with it is probably because of my weird use-cases (is not having a kb plugged-in so “out there” for a headless server?).

3 Likes

I gave it for very opposite reasons to my modus apperandi BUT what it seems to he is init agnostic as well which is why such a heavy unified kernel image actually garnered my approval. If you can use any init and arw agnostic about the initramfs, and kernel… Thats awesome and the ability to load it into a TPM verifiable chain. That would be a massive step forward in security. See ive got no issues if the bloat realistically does improve security from the standpoint of the potential vectors and I damn well love something that slows down physical access

See the reason regurgitating “physical access means your fucked” make you a meme (no offense) is because its nuanced. Yes the data is vulnerable but you HAVE A CHANCE to revoke the keys. ALSO looking at nmbl it appears one goal is the ability to load the UKI and key onto a USB. Thats even better. What does an attacker do with FDE when hes missing the entire needed mechanism to even attempt to decrypt and verify it once he finds a vulnerability. You could revoke the keys on USB drive storing after the device is stolen… Then thermite the USB or something :joy:. Pretty useless after that.

There are ways to DELAY and DENY access even when physical compromises occur and the WHOLE POINT is literally to delay them while you revoke and manage anything sensitive and vulnerable if the device is lost

So this project is pretty cool. Its not what I would call minimalism though

3 Likes

Isn’t grub more secure though when you reconfigure it to be on encrypted LVM2?

No. Please read the article linked above

The issue is FDE does nothing to prevent boot attacks and nothing to really delay anything on the physical access side nor is the FDE verified by a trusted boot process so all your really doing is encrypting the data which also isnt perfect. Particularly on SSDs with auto hardware level trim since luks/lvm can be made vulnerable by looking at discarded blocks if the old key is present

1 Like

Ok I read through it. Basically the idea is purge the bootloader idea altogether and run the bootup process on the TPM leveraging it’s different ECC algorithms and actively replacing the old data on the TPM during runtime + preventing TPM key access to old software that was signed by the TPM prior.

Makes sense I like it. I think Fedora should do this, they’re already experimenting with BTRFS.

1 Like

Wdym experimentimg with btrfs? Its been supported for a while now IIRC

Yeah its definitely a refreshing new concept!

1 Like

I just meant going against the curve I guess. They went to full support for BTRFS where ubuntu went with ZFS

1 Like

Ubuntu is shipping ZFS as part of the supported FS out of the installer. How do they keep the license issue at bay? Thats cool of they have found a way. I like that. ZFS >>>>> BTRFS easily

Actually that brings up an interesting point. How will nmbl deal with all the different FSes? If it limits support that may limit its adoption. I know ZFSbootmenu supports zfs so maybe numbl will take that code?

An encrypted OS / DATA drive can preserve the integrity of the encrypted data but does nothing to preserve integrity of the firmware or addition of devices to the mobo as GRUB does not verify the firmware or TPM as stated here:

and here:

I work with secure environments daily (and nightly…and on the weekends…and in my sleep)

Windows Server 2022 requires signed firmware verified with the TPM when you throw enough switches. If you merely move a PCIe device to another slot it’ll violate the secure boot chain, refuse to even prompt to unencrypt the drive and brick the system.

Linux shouldhave the same option path, but as stated above guys will shit a chicken when their machines refuse to boot after a hardware failure and replacement.

That said, if I have physical access I can merely input:
AAAAAAAAAAAAAAAAAAAAAAAAAAA
as the password into an older iLOM and trigger a buffer overflow followed by authentication. Most BMC’s share the screen buffer.
Mitigation: discrete GPU’s for rendering headless hypervisors and disabled the BMC gpu in the OS.

Which leads back to:

with a *
and I mean that as an asterisk and wildcard

There is a place for secure infrastructure, but at this time compiling firmware from source, signing with self issued keys, and verifying the bootchain through TPM yourself is practically infeasible.

2 Likes

I haven’t gotten to read the article yet.

Probably like how most systems deal with it: manually. The reason we need zfsbootmenu on encrypted (root-on-)zfs is because we need to decrypt the volume before we load our initramfs, which then loads the kernel modules to mount the zfs dataset. But zfsbootmenu doesn’t get loaded by itself, it’s initialized by the UEFI, as a EFI payload using the efistub.

If nmbl is supposed to replace grub, it’ll probably not have support for many file systems. I really don’t remember where I had to deal with it, I think I was using grub on some rando European cloud provider eons ago. I needed a /boot/efi vfat partition (for obvious reasons) and I couldn’t have /boot on my main drive (which was using LUKS-on-LVM), so I needed to do something stupid like ext4-on-LUKS for /boot to get the system to boot (because while grub technically supports lvm, it can’t read your initramfs from an lvm volume, or it couldn’t way back then).

So, grub would get loaded as an efi payload, prompt you for the /boot decryption key, then I think, when the initramfs was loaded, prompt you for the rootfs decryption key (because LVM needed to be activated and then you’d get the luks decryption prompt). You obviously don’t have that when you’re doing LVM-on-LUKS.

Just like that, nmbl will likely only support 1 type of file system (probably ext4, or worse, vfat eeeww) from where it can load the data properly, which then, your initramfs takes over.

Note: I could be completely wrong on the above, both about nmbl and about what was happening in that environment. The only thing I remember is that this was the solution I implemented to get it to work. And, boy, were reboots a royal PITA (if there was a server crash from OOM or something, I’d have downtime until I woke up and saw the alert in my monitoring tool that the server is down, which was obviously not a good thing, but I wasn’t really trusting that cloud provider). I needed to be present when reboots happened, to insert the decryption key. There’s probably a way to do that with automation via SSH now, but back then, I didn’t know of any other means.

2 Likes

Which is deeply unfortunate because if we want secure systems it should be accessible and with a far less steep barrier of entry learning curve

3 Likes

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.

4 Likes

I was also thinking this. It would be great for coreboot devices but all standard UEFI is a proprietary mess. Why TPM was never trusted to begin with, if I remember words straight from Wendell in the Tek Syndicate era. Not sure if much has changed since we’re still on proprietary UEFI with (almost guaranteed) backdoors to the TPM.

2 Likes

We did this on a dev ops server out of necessity of switching host OS’s frequently and we found enrolled keys could be added, deleted, and every other OS kept chugging right along as if it never happened because:

As far as TPM chips:

Short of an open source HSM, there’s really no options here.

The secure machines I work on are only safe against hostile foreign adversaries, not host or alliance nations. This is sufficient for the work they do.

To have a genuinely secure system takes a level of autism that is cherished in infosec, and starts with open source firmware, including UEFI, then builds to a roaring FOSS monster that requires time compiling updates rivaling the actual usable uptime.

All this with bizarre implementations and workarounds since so much is proprietary.