Re: [gentoo-dev] Re: Killing UEFI Secure Boot

[Richard Yao]

On 06/21/2012 04:08 AM, Duncan wrote:
> 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!
>

A firmware replacement for the BIOS does not need to worry about floppy
drives, hard drives, optical drives, usb devices, isa devices, pci
devices and pci express drives, etcetera, because those live on buses,
which the kernel can detect. It would need a device tree to inform the
kernel of what buses are available, but that would be specific to a
given board, rather than what is attached to it. If the end user makes
hardware changes, the kernel should be able to handle that, with the
exception of changes involving RAM, which I believe go into the device tree.

With that said, I am not convinced by your argument that x86 is
fundamentally more complex. Many of the things you attributed to the
BIOS are in fact handled by the kernel. There is plenty of duplication
between the two, where the BIOS will configure things and then the
kernel will configure them again. However, the BIOS does not accomplish
anything useful in those cases.