[gentoo-dev] Re: Killing UEFI Secure Boot

[Duncan]

Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as excerpted:

> 3. How does getting a x86 system to boot differ from getting a MIPS
> system or ARM system to boot? Does it only work because the vendors made
> it work or is x86 fundamentally harder?

I can answer this one.  x86 is harder at the bootloader stage, but in 
turn easier, or perhaps simply different, at the kernel and kernel device 
interface level.

Consider, most MIPS and ARM systems ship with a specific set of basic 
devices, configured to use specific IO addresses, IRQs, etc, and that's 
it, at least to get up and running (USB devices, etc, may be able to be 
plugged in, but they're not normally needed for boot).  If you've been 
keeping up with the kernel (say via LWN, etc), this has been one of the 
big deals with the ARM tree recently, as until now each "board" had its 
own hard-coded kernel config directly in the tree, and it was getting 
unmanageable.  They're switching to "device tree", etc, allowing the boot 
loader to feed the kernel a file with this information at boot time, thus 
allowing a whole bunch of different boards to boot off the same shipped 
kernel, while at the same time getting the explosion of individual board 
files out of the kernel tree.  This is a BIG deal on ARM and similar 
embedded archs, but doesn't affect x86 (either 32-bit or 64-bit) at all.

Meanwhile, on x86, the system must be prepared for end-user switch-out of 
pretty much everything. memory, storage (consider floppy, hard drive, 
optical disk either direct or el-torito, USB stick, etc, all bootable and 
all end-user changable!), even quantity and speed of CPUs, and the 
firmware BIOS (or replacement) must cope with that and be able to boot 
off it.  Even back in the 386 era when everything was jumper-configured, 
users could still change pretty much everything out, other than the mobo 
itself.   Now days, it's even MORE complex, as most of these devices can 
be configured in dozens or hundreds of mode combinations via "plug-n-
pray", and they often don't /have/ a default -- they **MUST** be so 
configured in ordered to be operable for the intended use.  Sure, the 
BIOS CAN leave some of it for the kernel to do, but other bits, not so 
much, as otherwise, how does the kernel even get loaded -- the BIOS must 
pick one of the many boot options, configure it (as well as the CPU and 
the system between storage and the CPU, storage chipset, memory, etc) at 
least well enough to read in the boot loader and/or kernel.  None of 
that's necessary on ARM, etc, because (pretty much) everything there's a 
totally arbitrary-as-shipped config, nothing to dynamically negotiate and 
get working before the kernel or secondary bootloader (after the BIOS) 
can even work!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman