Gentoo Archives: gentoo-genkernel

From: Richard Yao <ryao@g.o>
To: "gentoo-dev@l.g.o" <gentoo-dev@l.g.o>
Cc: gentoo-genkernel@l.g.o, Sabayon public development mailing list <devel@×××××××××××××.org>, funtoo-dev@××××××××××××.com
Subject: [gentoo-genkernel] Killing UEFI Secure Boot
Date: Tue, 19 Jun 2012 22:13:27
Message-Id: 4FE0F922.2090807@gentoo.org
1 I know that there is a great deal of discussion on the effect that UEFI Secure Boot will have on us. As far as I know, Secure Boot is implemented in the UEFI firmware and if we replace the firmware, Secure Boot issues disappear. With that in mind, I believe we can solve the Secure Boot problem by installing Gentoo on PC hardware like how OpenWRT is installed on routers.
2
3 http://wiki.openwrt.org/doc/techref/flash.layout
4
5 We can extend genkernel to produce images similar OpenWRT images. This image would have partitions. In particular, it would have one for the bootloader, another for the kernel and a third for an optional root filesystem. The bootloader partition would be further divided between boot code and the NVRAM, which would contain bootloader settings. The bootloader would read the NVRAM to obtain the kernel command line that it provides to the kernel and then boot it. THe kernel would then be responsible for initializing hardware and mounting the rootfs.
6
7 We will need boot code designed to start after RESET, read the NVRAM, configure the memory address space, load the kernel and jump into it. It would also handle any other things that either the kernel requires or that users want, such as a VGA text console before the kernel boots. A VGA console will require additional documentation from vendors, but routers seem to boot fine without it and our systems should too. x86 hardware emulates an 80386 environment at RESET, so we should be able to use documentation on 80386 to assist in development:
8
9 http://css.csail.mit.edu/6.858/2011/readings/i386.pdf
10
11 Das U-Boot and RedBoot are typically used on routers, but unlike RedBoot, Das U-Boot supports x86. In addition, the knowledge and tools necessary to develop on physical hardware are quite accessible:
12
13 http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/
14 http://www.sivava.com/EPROM_Programmer_5.html
15
16 Developing on physical hardware could be tedious and time consuming, so it would probably be best to develop this on virtual hardware first. VMWare in particular uses a Phoenix BIOS. My expectation is that developing this on VMware's virtual hardware will help avoid issues when development moves to physical hardware. In addition, instructions are available for booting custom BIOS images, which is precisely what we need to develop this:
17
18 http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html
19
20 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.
21
22 This should open the door to further genkernel extensions, such as the creation of an initramfs that provides a general purpose GRUB replacement. This would enable us to flash the BIOS only once and then boot newer kernels (or even other operating systems) by adding entries to the NVRAM. It would still be faster than Core Boot because the kernel in the BIOS chip should still be able to mount the rootfs and boot the system.
23
24 Does anyone have any thoughts, comments or suggestions?

Attachments

File name MIME type
signature.asc application/pgp-signature