From: Ian Stakenvicius <axs@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Killing UEFI Secure Boot
Date: Thu, 21 Jun 2012 11:00:10 -0400 [thread overview]
Message-ID: <4FE336FA.2030509@gentoo.org> (raw)
In-Reply-To: <4FE2EA62.1090407@gentoo.org>
-----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-----
next prev parent reply other threads:[~2012-06-21 15:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 22:11 [gentoo-dev] Killing UEFI Secure Boot Richard Yao
2012-06-20 0:22 ` Rich Freeman
2012-06-20 1:10 ` Richard Yao
2012-06-20 1:25 ` Rich Freeman
2012-06-20 1:33 ` Richard Yao
2012-06-20 1:51 ` Rich Freeman
2012-06-20 3:27 ` Peter Stuge
[not found] ` <1a28c6af40914cf5b6b5559bd0195a1b@HUBCAS1.cs.stonybrook.edu>
2012-06-20 22:16 ` Richard Yao
2012-06-21 8:08 ` [gentoo-dev] " Duncan
2012-06-21 9:33 ` Richard Yao
2012-06-21 15:00 ` Ian Stakenvicius [this message]
2012-06-21 15:05 ` Richard Yao
2012-06-21 18:55 ` Roy Bamford
2012-06-21 19:10 ` Peter Stuge
2012-06-21 22:51 ` Rich Freeman
[not found] ` <2279549d74ab41acb17b7207aa1478f6@HUBCAS2.cs.stonybrook.edu>
2012-06-22 0:24 ` Richard Yao
2012-06-22 13:02 ` Ian Stakenvicius
2012-06-22 5:02 ` Duncan
2012-06-22 5:10 ` Richard Yao
2012-06-22 5:30 ` Richard Yao
2012-06-20 20:08 ` [gentoo-dev] " Greg KH
2012-06-20 20:13 ` Richard Yao
2012-06-20 20:20 ` Greg KH
2012-06-20 20:35 ` Richard Yao
2012-06-20 21:09 ` Greg KH
[not found] ` <01ed9c34e80e4f66b9f5c9fbcdede39e@HUBCAS2.cs.stonybrook.edu>
2012-06-20 21:56 ` Richard Yao
2012-06-20 22:27 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE336FA.2030509@gentoo.org \
--to=axs@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox