[coreboot] Rettungsboot

Julius Werner jwerner at chromium.org
Tue Nov 29 22:53:15 CET 2016

> To sum it up, I want something that is lean and clean enough so it could
be added to any bootloader. Even if that boot loader is not of the
let's build a tiny OS type.

I don't really see how you could reach this goal with anything that
requires reading a file from the boot media? There are billions of
different file systems out there... do you want to require your
"minimal" bootloader to include drivers for all of them? (There are
bootloaders that don't contain any file system drivers at all, like
depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
every disk on a special FAT32 partition" madness (which still requires
bootloaders to include one specific FS driver they might otherwise not

I think if you want to do anything truly minimal and compatible with
everything, you can't rely on files (and you should try to rely on
partitions as little as possible, e.g. no full GPT parsing). Which
probably means putting it in the first sector. And once you have that,
you can create some fancy text-based format (or Go source file /
node.js script / whatever the cool kids use these days) to describe
the target sector, load address etc. of the fallback kernel... but
you're really just exemplifying the XKCD Igor mentioned because you've
just reinvented the MBR. (And let's face it... no coreboot bootloader
has the pull to sufficiently promote adoption of some completely new
fallback boot descriptor format right now, even if it doesn't require
a Go compiler in your bootloader.)

So, really, I think what you want is just the MBR. It is the deadest
simple design possible (just load a sector and jump), it is as
infinitely flexible as code itself, and it coexists perfectly with all
partitioning schemes relevant today (MBR and GPT). Yes, it requires a
software interrupt BIOS interface, but if the recovery kernel code is
cleverly written you really only need the disk access part (and you
know your bootloader already has that driver because that's how it
loaded the MBR in the first place). And yes, on x86 it requires real
mode (for non-x86 I'd just make up an as equivalent as possible system
with your software interrupt solution of choice), but that's a small
price you pay with a few files worth of shim code in exchange for
automatic compatibility with 35 years worth of existing BIOSes. I'd
say that's a better deal than any new dead-on-arrival scheme you could
make up out of thin air.

(If you really can't stand the idea of BIOS interrupts and real mode,
I think your next best option would be to try to cram an
as-small-as-possible binary recovery descriptor and the real mode code
to parse/load/execute it together into the 446 bytes of MBR space you
have. This way, your new payloads can just find and parse/load/execute
the descriptor itself without having to provide any BIOS interface,
but the thing is still compatible with existing legacy BIOSes as

More information about the coreboot mailing list