Gentoo Archives: gentoo-dev

From: Richard Yao <ryao@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Killing UEFI Secure Boot
Date: Fri, 22 Jun 2012 05:33:14
Message-Id: 4FE402F9.8070007@gentoo.org
In Reply to: Re: [gentoo-dev] Re: Killing UEFI Secure Boot by Richard Yao
1 On 06/22/2012 01:10 AM, Richard Yao wrote:
2 > On 06/22/2012 01:02 AM, Duncan wrote:
3 >> Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
4 >>
5 >>> A firmware replacement for the BIOS does not need to worry about floppy
6 >>> drives, hard drives, optical drives, usb devices, isa devices, pci
7 >>> devices and pci express drives, etcetera, because those live on buses,
8 >>> which the kernel can detect.
9 >> But you have to be able to load the kernel first, before it can do all
10 >> that detection. And to load it, you need to be able to read the device
11 >> it's located on, which in a modern x86 system (as contrasted with mips/
12 >> arm) generally means detection of what's there, some mechanism to choose
13 >> which available devices to check for a kernel or boot loader or whatever,
14 >> and some way to dynamically configure it, since many devices are simply
15 >> (device info probable) bricks until configured, these days.
16 >>
17 >> Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
18 >> S suggested), but then you're back to hard-configuring it in ordered to
19 >> do so, thus losing all that extra flexibility that's part of what makes
20 >> x86 different. Which was the question that I was addressing.
21 >>
22 > Placing it in the firmware is what I suggested. I also later stated that
23 > it is possible for the firmware to contain an initramfs that would
24 > enable it to start a kernel located on a device.
25 >
26 > It seems to me that this would work if device trees for motherboards
27 > were readily available and the EEPROM chips have sufficient capacity. I
28 > am under the impression that UEFI firmware is large enough that capacity
29 > on UEFI motherboards should not be an issue. The main issue would be
30 > obtaining device trees.
31 >
32 Before anyone says it, information on how to initialize the memory
33 controller and possibly a few other bits prior to loading the kernel is
34 also necessary. I omitted that by mistake.