Gentoo Archives: gentoo-genkernel

From: Richard Yao <ryao@g.o>
To: gentoo-dev@l.g.o
Cc: Sabayon public development mailing list <devel@×××××××××××××.org>, core@××××××.org, gentoo-genkernel@l.g.o
Subject: [gentoo-genkernel] Re: [gentoo-dev] Killing UEFI Secure Boot
Date: Wed, 20 Jun 2012 01:12:15
Message-Id: 4FE1230D.8090502@gentoo.org
On 06/19/2012 08:22 PM, Rich Freeman wrote:
> On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ryao@g.o> wrote: >> I know that the Core Boot project also tries to accomplish this, but
their development process is slow and their approach seems to make the boot process more complicated than it needs to be. Since Secure Boot will force us to flash our BIOS chips (or stick to old hardware), I think it would be worthwhile to develop our own solution by extending genkernel. This should have the benefit of making our systems boot faster.
> > So, replacing a BIOS is a fairly tall order - I'm not convinced that > Core Boot is slow simply because they're doing it wrong. They're also > looking to add value (like booting a diskless server off of a random > website or whatever - not just simple disk/PXE like most BIOS). My > understanding is that clusters are one of their big use cases.
Core Boot is a Linux distribution. I do not think that we should boot Gentoo using their distribution any more than we boot Gentoo using RHEL.
> I also don't get the claim that we need to flash our BIOS chips to get > around secure boot. If you don't want to use secure boot just disable > it - it is no harder than changing your boot device order, system > time, or any of a myriad of other firmware settings. It gets more > complicated if you want to keep secure boot but boot your own OS, > since you have to manage the keys/signing/etc.
In theory, the kernel could be modified to only execute signed binaries and portage could be modified to produce signed binaries. The user could build a system that required everything to be signed with the private key of his choice. A hardened system that required signed binaries would be even more secure than a typical system using Secure Boot where only the bootloader, kernel and kernel modules are signed. The user would be in full control of his hardware. The user would not need to pay for this and the system would also boot faster.
> Nothing is keeping anybody from creating their own firmware. However, > I doubt we'll see 25 devs take this on as a full-time job, which is > probably what it would take to support the bazillions of boards out > there. Keep in mind that many motherboard vendors require signed > firmware so you'll need to find an exploit for every make/model out > there to even load your firmware. That seems a bit much compared to > just disabling secure boot...
The 80386's RESET state is emulated uniformly across all x86 and amd64, so it should not take much effort to support the basic functions of setting up the CPU, loading the kernel (from the EEPROM) and jumping into it. Everything else is secondary. Those are the only things that a BIOS replacement needs to do. As you pointed out, Core Boot is trying to add value. That means that they are doing far more than those basic functions. Other features are nice, but not if they get in the way of being able to boot. Other things can come the system boot process works. Basic functionality would only require the work of a few people. Things beyond that (e.g. pre-kernel VGA console initialization, pre-kernel networking, etcetera) might require vendor support through documentation. I would be thrilled if 25 developers wanted to work on this full time, but I am not certain that would make sense. Linux already has thousands of developers working on hardware support, including developers from Intel. We should be able to leverage that. Did I miss any technical obstacles?