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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/06/12 05:33 AM, Richard Yao wrote:
> 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.

I take it the above statement is based on the kernel being directly
placed within the BIOS/firmware/nvram on the board, such that you
couldn't boot anything else but that kernel?  Otherwise I don't see
how you could get away with the BIOS not worrying about all those
devices..  IE, I don't forsee many general x86 users giving up their
ability to boot off usb stick or cdrom or pxe based on a boot-time
bios choice, or to boot windows or alternative linux kernels (which
could be located who knows where) at whim.  And I don't see how an
alternative BIOS would be able to provide this ability without dealing
with all the things Duncan mentioned...


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU
7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI
=CwME
-----END PGP SIGNATURE-----