I'll go ahead and add my two cents. Although I haven't successfully programmed an actual bootloader, I do some have experience making EFI programs.
The UEFI specification details a "System Table" (https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html), from which the program may access system services, if the system doesn't have the proper drivers. Likewise, since Linux has various drivers for almost every hardware device, the kernel itself will enumerate hardware devices through ACPI, or a devtree interface/blob, the latter being grabbed by the bootloader: https://lwn.net/Articles/367752/. Hard drives generally follow a single standard, and are easy to account for as hardware, given you have the drivers for their given controller. NVMe drives are basically an SSD *and* controller in one, since they are directly plugged into the PCIe bus. Basically, the bootloader simply has to load the kernel image into memory, and importantly, verify the image, and then pass a couple of parameters to the kernel, before issuing a jump instruction to it. All that the bootloader is concerned with, is loading, and verifying that the image is valid. A perfect bootloader wouldn't even touch a filesystem at all, and instead, directly pull the kernel image from the hard drive via an offset+size baked directly into the bootloader's binary. However, kernel configurations must be done via the bootloader, due to how the kernel is written (as far as I know), which must also be configured via a file, so we don't live in this theoretical perfect world. Kernel verification would preferably be done via a TPM module. I don't know how this works, so I cannot really detail this process. If you want to figure out how TPM *may* work, and have the time to do so, there are TPM specification documents here: https://trustedcomputinggroup.org/resource/tpm-library-specification/ I do believe it is more trivial then most people think, to make a unified bootloader that works across different architectures and hardware models, in particular, for those with the necessary expertise and knowledge to do so. If it turns out that they cannot do so because of undocumented hardware, that would be a separate problem entirely (although all too familiar in the world of Linux). Fortunately, various vendors have put an effort to open source their hardware interfaces, so undocumented hardware isn't as much of a problem nowadays as it was in the past. This is part of the reason why Linux is so good now, when compared with its past. Building on top of GRUB isn't the best solution in my opinion, although it is *way* better than doing nothing. I know that many cloud companies and individuals alike, want to ensure the safety of their data, which is a respectable goal. Sent with Proton Mail secure email. On Tuesday, June 23rd, 2026 at 06:22, Neal Gompa <[email protected]> wrote: > On Tue, Jun 23, 2026 at 6:07 AM Gerd Hoffmann <[email protected]> wrote: > > > > Hi, > > > > > From the Fedora Cloud point of view, I am generally supportive of > > > this. I would like to see other common filesystem modules re-added > > > though (particularly btrfs, but it also probably makes sense to re-add > > > xfs and ext4). I have had a todo item for a while now to discuss > > > extending grub to s390x like the SUSE folks do for similar reasons. > > > > I'd rather see the fat driver removed and grub using > > EFI_SIMPLE_FILESYSTEM_PROTOCOL instead. > > > > > Having a unified chain across all architectures that gives us a > > > consistent set of features allows us to have focused integration > > > points in userspace and develop failure mode handling that works > > > regardless of the platform. > > > > That is IMHO an illusion. The boot loader can't hide the platform > > differences. > > > > I didn't say anything about illusions. The point of GRUB is to provide > a common layer regardless of the underlying platform. > > I still get a consistent feature set, I get a stable configuration > target, and a universal way to detect platform differences and adapt > to them. > > > Look, grub started as boot loader for x86 bios systems. That is > > firmware with a very limited feature set. So grub brings its own > > drivers for pretty much everything. And that history is still very > > present today in the grub code base. > > > > I know how these things started, I started with Linux using LOADLIN > and later LILO and finally GRUB today. I'm not unfamiliar with how all > this works. :) > > > UEFI arrived, with alot more features. grub continues to use its > > own drivers, causing conflicts at times because both the grub driver > > and the efi driver are active at the same time. Also grub completely > > ignores features provided by the firmware. For starters the grubenv > > file with all its problems such as grub needing write access to the > > filesystem for updates IMHO doesn't make much sense on UEFI systems > > because grub could store that data in EFI variables instead. > > > > EFI variables are horribly broken in practice. I don't know if you > happen to have perfect computers, but like half of my real-world test > machines and two of my daily driver computers have either > failed-with-success, non-writable, or otherwise non-functional EFI > variables. And with fake/emulated EFI systems like U-Boot and whatnot, > these things work even less well. > > As a general rule, I want to minimize the reliance on the firmware > layer and jump into stuff we have as quickly as possible. > > > > And being able to leverage filesystem features to provide defense > > > in-depth around data integrity is something David and I have been > > > exploring and engaging with upstreams on as well. > > > > Why "filesystem features" and "data integrity" is something boot > > loaders should have to care about? > > > > Well, at least from GRUB's point of view, currently they don't, but in > the future, it could. For example, if fsverity is "broken" on a file, > then GRUB could refuse to read the file. This can even extend further > with UKIs to halt the boot process. > > There are lots of opportunities to be smart early and do it in a way > that provides a consistent experience. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
