Why though?

> > Ah, so shim is you boot menu/arbiter between multiple kernels then and implements boot counting and stuff?

> That's I think what they're going for, I'm not sure they're implementing the boot counting idea, I don't think there's a strong need to count successful _early_ boot.

There's so much to fail there, for example signature checks and stuff.

> > Not sure I grok this. The job of pivoting to the root fs is the job of the initrd, so you are just describing an initrd here?

> See it's reasonable clever: If you want to boot the same kernel that is in the nmbl UKI, we can just skip the whole kexec shenanigans altogether and improve boot speed. The whole boot menu thing is more or less a fallback or expert mode feature.

But that's so wrong: kexec in itself is one of those things that are a source of problems, i.e. outside of well-known hw environments drivers are not universally ready to recover from a kexec handover. So with this "clever" approach, when something goes wrong and you revert to an older version you suddenly pull another major source of problems in your boot paths? So in an attempt to make things better you make it substantially worse?

Also, if you have A/B stuff in shim anyway, why not just use that for pick boot paths and just dumping the later userspace stuff? I mean, you just reinvented sd-boot in shim, then, which while I am not a fan of I cannot claim wasn't a workable solution.

> > But that boot menu is *after* the kernel is already invoked? what's that good for? It's too late! At that pointas I understand you already initialized a full kernel with network drivers, graphics drivers, input drivers, TPM stuff, complex storage I understand you? So what's the point in putting a menu at a place where the ship has already sailed and all the risky stuff that can go wrong already happened?

> You only really need an A/B boot mechanism and essentially what the plan here is, is to put that mechanism into shim itself. Then shim can fall back to the good nmbl UKI.

So sd-boot is basically an A/B boot mechanism too, except we support not just A and B but A/B/C/D/E/F… If the core of the idea is to have that I am just wondering why bother with nbml at all...

> Personally I have two other approaches where I either

> 1) have two boot entries in UEFI, and I either set BootNext to attempt switching the kernel, and record the working kernel in boot-complete.target, or
> 2) I have the old one kexec the new one and then continue with boot-complete.target successful boot marking.

Most folks I talk to suggest we should avoid writing to NVRAM too regularly, and hence better do the arbitration on disk.

> Notably that's not all the risky bits; the main regressions I see in a kernel update are usually not early boot failures but stuff like your graphic driver acting up or resume ends up failing which you only notice after potentially a long run time. Then you want to be able to potentially have more fallback options to pick from then just the A/B.

As somebody who works on init systems, initrds, and so on I can tell you that a major chunk of failures is boot-time stuff. probably at least 50% of fatal issues with updates.

> > Moreover, how do you actually intend to guarantee the crptographic integrity of that journaling file system? A complex file system you *have* to authenticated *before* you parse things

> Frankly you don't need to care; the ship has sailed, your booted OS will not be verifying it's cryptographic integrity anyway.

It won't? In my world they all do. It's kinda what the systemd cabale is kinda working towards: ensuring that stuff that is not authenticated, not measured cannot corrupt the boot process. Hence, parsing a complex fs without ensuring its integrity first somehow is an absolute and complete nostarter in our eyes.

Sorry, but in 2024 it shouldn't be good enough to design new systems that do not validate things like that.

> And then the worst offender is systemd-gpt-auto-generator anyway, which will happily mount any untrusted partition with the right GUID over your trusted authenticated root (yes yes you can constrain it *now* on 254, but the introduction of that feature was a mess) :D

Nah, it's not that simple. At MSFT there was always an LSM that ensures restrictions are made on mounts, so that we can require that the only file systems that can be mounted are either dm-crypt or dm-verity backed (or vfat). Google for "IPE LSM" for details.

Yes, s-g-a-g shouldn't even *try* to mount things like that in a secure environment (and now it doesn't anymore), but the primary line of defense really should be an LSM such as IPE here, not things like s-g-a-f image policies.

> > The network aspect I don't get either. So in your model shim and nmbl would have to be placed on the local ESP, and the 2nd stage kernel is then placed on http or so? so what's the point of this model? You have to set up things locally *and* remotely now?

> You could be HTTP booting a remote nmbl only. Now obviously that's no concern of RH, but if you consider a product like Canonical's MAAS, the remote boot loader then chainloads the local one (after all when the machine boots the central management server might want to reprovision it), you'd want to be able to replicate that.

> You can't just pivot roots between two different userspaces, the remote boot loader of the management system may be Ubuntu but you want to install a RHEL or something.

I am not sure I follow anymore. Sounds adventurous to me...