Re: [gentoo-dev] Killing UEFI Secure Boot

[Richard Yao]

Peter, thanks for the detailed email. I have a few questions.

1. As far as I know, Das U-Boot and Core Boot are mutually exclusive.
Why should Linux distribution developers want to use Core Boot instead
of Das U-Boot?
2. It seems to me that you do not need any Linux code. Exactly what is
the relationship between the Core Boot codebase and the Linux codebase?
3. How does getting a x86 system to boot differ from getting a MIPS
system or ARM system to boot? Does it only work because the vendors made
it work or is x86 fundamentally harder?

On 06/19/2012 11:27 PM, Peter Stuge wrote:
> 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
>