From: Richard Yao <ryao@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: Killing UEFI Secure Boot
Date: Fri, 22 Jun 2012 01:30:33 -0400 [thread overview]
Message-ID: <4FE402F9.8070007@gentoo.org> (raw)
In-Reply-To: <4FE3FE31.3040706@gentoo.org>
On 06/22/2012 01:10 AM, Richard Yao wrote:
> 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.
>
Before anyone says it, information on how to initialize the memory
controller and possibly a few other bits prior to loading the kernel is
also necessary. I omitted that by mistake.
next prev parent reply other threads:[~2012-06-22 5:33 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
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 [this message]
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=4FE402F9.8070007@gentoo.org \
--to=ryao@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