Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Peter Stuge <peter@...>
Subject: Re: Killing UEFI Secure Boot
Date: Wed, 20 Jun 2012 05:27:52 +0200
Hi, I have about 11 years of experience with coreboot. I got
involved while developing a custom BIOS for an embedded system.

You may already have caught some presentation I or one of the other
developers have made about the project. There's a bunch of links
over at http://www.coreboot.org/Screenshots


Richard Yao wrote:
> Core Boot is a Linux distribution.

Sorry sir, but no.

coreboot (one word, lowercase) is an open source BIOS replacement.

Proprietary BIOSes do two things:

1. hardware initialization
   on http://stuge.se/pc2010.png everything red requires init by firmware

2. starts an operating system
   this means implementing the BIOS Boot Specification, running
   master boot record code into real mode segment 7c00h, eltorito
   CD-ROM extensions and all of that crap

coreboot does step 1. and nothign else, and significantly faster than
common proprietary BIOSes.

When coreboot is done it starts another, separate, program, we call
that program "the payload."

The payload and coreboot are stored together in the boot flash, but
are not linked together. The payload can be any bare-metal program.

There are many legacy-free bootloader payloads, including GRUB2 and
gPXE/iPXE/whateverit'scalledtoday, but it can just as easily be an
operating system kernel or an embedded application if no OS is
needed. Boot flash are often 32Mbit today, so Linux and a small
initramfs fits comfortably.

The default payload is SeaBIOS, which is also the firmware QEMU uses.

SeaBIOS is an open source legacy BIOS implementation, and the
combination of coreboot and SeaBIOS provides a legacy-compatible
boot environment that starts your system exactly like an
old-fashioned proprietary BIOS.

With coreboot my laptop boots from power button to firefox in a
little over 8 seconds. Out of that time, coreboot runs for about
600 milliseconds. This is a fairly typical number.


> 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.

This is word for word what the founders of the coreboot project (then
called LinuxBIOS) thought back in 1999, and it blew up in their face.

In the following 15 years hardware has gotten significantly more
complex, and significantly more closed, again please have a look
at http://stuge.se/pc2010.png

The closer you are to the CPU the more impossible it is to acquire
reliable documentation for how to program the hardware.


> Those are the only things that a BIOS replacement needs to do.

Please join the project! If you find lowlevel programming interesting
it is an amazing good time, even if progress is slow at times. Now is
a fantastic time to get involved! For the first time in the history
of the project, there is code in the repository for all current
hardware platforms from both AMD and Intel.


> they are doing far more than those basic functions

I hope I've been able to clarify that actually coreboot does nothing
other than what is neccessary. This is the very essence of coreboot.


> Basic functionality would only require the work of a few people.

I'm afraid that this is rather naive.

An experienced coreboot developer given all required documentation[1]
(and ideally some 100-1000k EUR/USD worth of test equipment) can
possibly do a port to a new hardware platform (new CPU and chipset)
in twelve to eighteen months full time.

A hard core developer but without previous experience from PC
firmware and coreboot should add some six months for loading the
domain into her head.

[1] For Intel this requires two stages of NDAs and a decent business
case where Intel will sell five-six figure amounts of chips, or fewer
chips but to an important customer.

In contrast, AMD put the documentation on their webpage.

NVIDIA did not give the documentation to anyone no matter what the
business case. VIA doesn't publish documentation on the web, but
some coreboot developers do have good relations with them.


Over the last couple years Google have hired most of the active
coreboot developers including the project founder, and they've been
working on support for Intel's Sandy Bridge and Ivy Bridge platforms,
which powers the new Chromebook. I do not know how much time they've
spent, but from my outside view I estimate that it took this amazing
team of engineers between 25 and 30 man-months. This may be a very
optimistic estimate.

These new Intel platforms require a blob, firmware for a
microcontroller in the chipset, which runs while the main CPU is
still held in reset, in order to do some early prepararation of the
system.

The firmware blob is signed by Intel. I don't know if the signature
scheme has been broken, I guess it might at some point, but that will
likely be by the usual IT security crowd suspects.

In Google's coreboot code they are using Intel's reference code for
initializing the memory controller. This is so far also a blob, again
as opposed to AMD who have released their reference code under dual
BSD and GPL license, and although it is theoretically possible to
replace this with self-written code that is not really economical.

Please look through the SDRAM, DDR and DDR2 self-written init code
in coreboot for the various platforms, and then think about the
complexity added by DDR3, and I expect that hardware vendors and
JEDEC are hard at work on DDR4.

Memory controller init involves among other things a brute force
search of electrical signal drive strengths to find the correct
setting for stable operation.


> Linux already has thousands of developers working on hardware support,
> including developers from Intel. We should be able to leverage that.

Forget about that. Everything that happens on the Linux level is
really a different matter.


> Did I miss any technical obstacles?

PCs have 35 years of hardware legacy. It's quite possibly the worst
pile of hardware crap on top of hardware crap you can imagine. It's
a feat that anything works at all.

You mention 80386, but all PCs still start in real mode, 8086 style.
In another five or ten years maybe that will change, and (some)
hardware will become much more locked down. But I'm not sure, DOS
remains a significant market.

Someone said "Intel make the best x86 emulators." and that is spot
on. Besides that microcontroller inside your CPU there's of course
also the CPU microcode. There are no modern x86 machines.


FSF has long considered coreboot a high priority project, because it
makes UEFI irrelevant, and it very much puts users in full control,
while at the same time being transparent thanks to the open source.

They don't do much in terms of contributions though. I can understand
that. The way for coreboot to become relevant is to ship from factory.
Everyone with experience from the IBV (Independent BIOS Vendor)
industry knows what a special marketplace this is. It's very
interesting, but don't let anyone tell you that anything is easy.

The technical obstacles are the least of the problems.


//Peter


References:
Re: Killing UEFI Secure Boot
-- Rich Freeman
Re: Killing UEFI Secure Boot
-- Richard Yao
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Killing UEFI Secure Boot
Next by thread:
Re: Killing UEFI Secure Boot
Previous by date:
Re: ebuild laziness and binpkg overhead
Next by date:
Re: ebuild laziness and binpkg overhead


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.