Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Ian Stakenvicius <axs@g.o>
Subject: Re: Re: Killing UEFI Secure Boot
Date: Thu, 21 Jun 2012 11:00:10 -0400
-----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-----


Replies:
Re: Re: Killing UEFI Secure Boot
-- Richard Yao
References:
Re: Killing UEFI Secure Boot
-- Rich Freeman
Re: Killing UEFI Secure Boot
-- Richard Yao
Re: Killing UEFI Secure Boot
-- Richard Yao
Re: Killing UEFI Secure Boot
-- Duncan
Re: Re: Killing UEFI Secure Boot
-- Richard Yao
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: Killing UEFI Secure Boot
Next by thread:
Re: Re: Killing UEFI Secure Boot
Previous by date:
Re: My wishlist for EAPI 5
Next by date:
Re: Re: Killing UEFI Secure Boot


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.