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:12:27
Message-Id: 4FE3FE31.3040706@gentoo.org
In Reply to: [gentoo-dev] Re: Killing UEFI Secure Boot by Duncan <1i5t5.duncan@cox.net>
On 06/22/2012 01:02 AM, Duncan wrote:
> Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted: > >> 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. > > But you have to be able to load the kernel first, before it can do all > that detection. And to load it, you need to be able to read the device > it's located on, which in a modern x86 system (as contrasted with mips/ > arm) generally means detection of what's there, some mechanism to choose > which available devices to check for a kernel or boot loader or whatever, > and some way to dynamically configure it, since many devices are simply > (device info probable) bricks until configured, these days. > > Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian > S suggested), but then you're back to hard-configuring it in ordered to > do so, thus losing all that extra flexibility that's part of what makes > x86 different. Which was the question that I was addressing. >
Placing it in the firmware is what I suggested. I also later stated that it is possible for the firmware to contain an initramfs that would enable it to start a kernel located on a device. It seems to me that this would work if device trees for motherboards were readily available and the EEPROM chips have sufficient capacity. I am under the impression that UEFI firmware is large enough that capacity on UEFI motherboards should not be an issue. The main issue would be obtaining device trees.

Replies

Subject Author
Re: [gentoo-dev] Re: Killing UEFI Secure Boot Richard Yao <ryao@g.o>