Certainly escaping the hell that x86 puts you in early in the boot process requires a bit of assembler, yes. I think we're mostly talking past one another sema

Certainly escaping the hell that x86 puts you in early in the boot process requires a bit of assembler, yes. I think we're mostly talking past one another semantically if you believe that "most of what a bootloader does is calling arch-specific opcodes." Most projects I'm familiar with called "bootloader" (including coreboot, GRUB/LILO, etc.) are by and large, both by lines of code and complexity, focused on loading binary files from disk using a filesystem driver, parsing them (!!!), and then passing off execution - all tasks which are better handled by a language or framework where it's not so easy to make a parsing mistake which compromises an entire system. This is true especially once trust chain verification and cryptography are also thrown into the mix. Now that you've gotten me thinking about it as well, static verification of the real mode portion of a bootloader should be entirely possible. Although I'm not sure of a good toolset for doing so off the top of my head, there's nothing theoretically stopping someone from implementing a safe(ish) system which is capable of assembling software which could operate in real mode. Anyway, since it seems unclear: my main thesis is "introducing Linux to the trust verification part of your boot process seems rather ridiculous because it is a gigantic surface area implemented in a way that makes it exceptionally challenging to audit."