> a small first-stage bootloader written in a safer language than C
Given that most of what a bootloader does is calling arch-specific opcodes to initialize the memory model et al (and C is used mostly because it can embed the assembler to make those calls, but also lets you break away from it now and then to do some complex math more readably [i.e. on named variables instead of using explicit registers]), what do you gain by using a language other than C?
> written in a memory-safe language
What does this even mean in bootloader land, when you're starting off in real mode without the GPT enabled, and writing to raw memory addresses rather than to any allocation known as "the heap" or "the stack" or "the data segment"?
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."
every compiled code is assembly. C was considered very high level, at some point in history.
> What does this even mean in bootloader land
that your disk encryption password input can't override the program data that will later on write to some bios memory address, for example. who knows? If I knew they wouldn't be undiscovered bugs, but CVEs :)
The assembler isn't interleaved with C, it runs first; once the setup is complete, control is transferred to C. I think this is the pattern that should be followed as much as possible: small platform-specific bits, then switch to higher-level language runtime. Certainly as soon as you're parsing input or doing cryptography a high level language becomes an advantage (with the requirement to call back to low-level occasionally). Rust seems to be the closest match here.
Given that most of what a bootloader does is calling arch-specific opcodes to initialize the memory model et al (and C is used mostly because it can embed the assembler to make those calls, but also lets you break away from it now and then to do some complex math more readably [i.e. on named variables instead of using explicit registers]), what do you gain by using a language other than C?
> written in a memory-safe language
What does this even mean in bootloader land, when you're starting off in real mode without the GPT enabled, and writing to raw memory addresses rather than to any allocation known as "the heap" or "the stack" or "the data segment"?