FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-19-2012, 10:11 PM
Richard Yao
 
Default Killing UEFI Secure Boot

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.

http://wiki.openwrt.org/doc/techref/flash.layout

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.

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:

http://css.csail.mit.edu/6.858/2011/readings/i386.pdf

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:

http://openschemes.com/2009/10/20/installing-a-plcc-eeprom-socket-onto-a-mobo/
http://www.sivava.com/EPROM_Programmer_5.html

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:

http://pete.akeo.ie/2011/06/extracting-and-using-modified-vmware.html

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.

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.

Does anyone have any thoughts, comments or suggestions?
 
Old 06-20-2012, 12:22 AM
Rich Freeman
 
Default Killing UEFI Secure Boot

On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ryao@gentoo.org> 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.

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.

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

Rich
 
Old 06-20-2012, 01:10 AM
Richard Yao
 
Default Killing UEFI Secure Boot

On 06/19/2012 08:22 PM, Rich Freeman wrote:
> On Tue, Jun 19, 2012 at 6:11 PM, Richard Yao <ryao@gentoo.org> 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?
 
Old 06-20-2012, 01:25 AM
Rich Freeman
 
Default Killing UEFI Secure Boot

On Tue, Jun 19, 2012 at 9:10 PM, Richard Yao <ryao@gentoo.org> wrote:
> On 06/19/2012 08:22 PM, Rich Freeman wrote:
> 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.

Well, maybe it is a distro in the sense that genkernel or dracut are
distros (they bundle a bunch of tools in conjunction with a kernel to
do something). The whole point of Core Boot is to be a BIOS
replacement - either to do work on its own, or to boot something else.
Like UEFI it aims to do more than just load one sector off the hard
drive, check for a magic number, and jump into it.

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

You can do all of this with the UEFI firmware that will come with your
computer already. Why replace it?

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

Fair enough, and the fact is that most modern OSes depend little on
the BIOS for much of anything. I'm not sure that is absolutely
nothing, but obviously the Core Boot folks have it working in some
cases.

>
> 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.
>
> Did I miss any technical obstacles?

Honestly, I'd probably ask one of the Core Boot folks. Has anybody
already tried to make a core boot light? If their system already
works on any board out there, then we're re-inventing the wheel. If
theirs doesn't, then we need to ask why, since we're likely to run
into the same barriers.

In any case, this seems like a solution to a problem that we don't
have. Any win7-certified motherboard is doing to be able to boot
without secure boot just fine, so why do we need to replace it with a
minimal firmware that does the same thing? I can see why one might
want to improve on it, with Core Boot and such. However, I suspect
the last thing we want in the Gentoo handbook is for every newbie to
be flashing a Gentoo-made firmware onto their board and we get to deal
with the bricks.

Rich
 
Old 06-20-2012, 01:33 AM
Richard Yao
 
Default Killing UEFI Secure Boot

On 06/19/2012 09:25 PM, Rich Freeman wrote:
>> 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.
>
> You can do all of this with the UEFI firmware that will come with your
> computer already. Why replace it?

We would gain a faster boot process. We would also enable people to
avoid paying money for keys that can be revoked without a refund.

I would rather people make donations to the Gentoo Foundation
voluntarily than to Verisign out of necessity, but that is just me.
 
Old 06-20-2012, 01:51 AM
Rich Freeman
 
Default Killing UEFI Secure Boot

On Tue, Jun 19, 2012 at 9:33 PM, Richard Yao <ryao@gentoo.org> wrote:
> On 06/19/2012 09:25 PM, Rich Freeman wrote:
> We would gain a faster boot process. We would also enable people to
> avoid paying money for keys that can be revoked without a refund.
>

While I have no doubt that a determined team could make a firmware
that booted marginally faster, I don't get the bit about not paying
for keys.

You don't have to pay anybody for a key to boot with UEFI - you just
need to either disable secure boot, or install your own keys. I can't
see how installing your own keys is going to be harder than flashing
the entire BIOS, and if you still want secure boot presumably you
still have to install your own keys.

If somebody wants to make a generic UEFI bootloader for PCs they
should by all means do so - I'm sure people would find use for it. I
just don't see it as an essential ingredient for Gentoo. If I really
wanted to mess with my BIOS I'd probably be loading core boot on it.

Rich
 
Old 06-20-2012, 03:27 AM
Peter Stuge
 
Default Killing UEFI Secure Boot

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
 
Old 06-20-2012, 08:08 PM
Greg KH
 
Default Killing UEFI Secure Boot

On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> 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.

Stop right there. That's just not going to happen, sorry. You aren't
going to be able to get a user to replace their BIOS, nor should you
ever want to. You are not going to be able to keep up with the
hundreds, if not thousands, of different motherboards being introduced
every month, in order to just get rid of the secure boot option.

You have a much better chance of just telling the user, "Disable the
Secure Boot option in your BIOS". "No, that doesn't mean that Linux
isn't secure." "Yes, I understand it looks that way."

And the conversation degenerates from there.

Sorry, not a valid solution.

And I want secure boot on my machines, with a key I trust, don't you?
If not, why not? I know lots of others that also want this, why deny
them the ability to run Gentoo on their hardware?

greg k-h
 
Old 06-20-2012, 08:13 PM
Richard Yao
 
Default Killing UEFI Secure Boot

On 06/20/2012 04:08 PM, Greg KH wrote:
> On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
>> 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.
>
> Stop right there. That's just not going to happen, sorry. You aren't
> going to be able to get a user to replace their BIOS, nor should you
> ever want to. You are not going to be able to keep up with the
> hundreds, if not thousands, of different motherboards being introduced
> every month, in order to just get rid of the secure boot option.

OpenWRT does that with routers and Cyanogenmod does that with phones. It
seems reason for us to offer it as an option to users. With that said,
this probably won't happen. One of the Core Boot developers informed me
of what is involved in setting up the address space and it is infeasible
for us to do.

> And I want secure boot on my machines, with a key I trust, don't you?
> If not, why not? I know lots of others that also want this, why deny
> them the ability to run Gentoo on their hardware?

To be clear, I was not talking about taking away options from users. I
was talking about giving them options.
 
Old 06-20-2012, 08:20 PM
Greg KH
 
Default Killing UEFI Secure Boot

On Wed, Jun 20, 2012 at 04:13:46PM -0400, Richard Yao wrote:
> On 06/20/2012 04:08 PM, Greg KH wrote:
> > On Tue, Jun 19, 2012 at 06:11:46PM -0400, Richard Yao wrote:
> >> 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.
> >
> > Stop right there. That's just not going to happen, sorry. You aren't
> > going to be able to get a user to replace their BIOS, nor should you
> > ever want to. You are not going to be able to keep up with the
> > hundreds, if not thousands, of different motherboards being introduced
> > every month, in order to just get rid of the secure boot option.
>
> OpenWRT does that with routers and Cyanogenmod does that with phones.

No, neither of them replaces the BIOS in their machines with an
opensource version. There is no BIOS in those platforms, it's just
uboot or fastboot, the PC-like ecosystem is so vastly different it's
laughable.

> It seems reason for us to offer it as an option to users. With that
> said, this probably won't happen. One of the Core Boot developers
> informed me of what is involved in setting up the address space and it
> is infeasible for us to do.

And I agree with that developer.

Don't get "replace all of userspace and the kernel" confused with
"replace the UEFI bios". You do realize that the UEFI bios is at least
double the size of the Linux kernel, with custom device drivers and tons
of other stuff in there? Good luck replacing that...

> > And I want secure boot on my machines, with a key I trust, don't you?
> > If not, why not? I know lots of others that also want this, why deny
> > them the ability to run Gentoo on their hardware?
>
> To be clear, I was not talking about taking away options from users. I
> was talking about giving them options.

You are taking secure boot out of their systems, that sounds like taking
away an option to me

Anyway, it's all a moot point, as has been explained already, sorry.

greg k-h
 

Thread Tools




All times are GMT. The time now is 10:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org