Re: [Hampshire] [OT] UEFI Secure Boot

Top Page

Reply to this message
Author: James Courtier-Dutton
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] [OT] UEFI Secure Boot
On 24 September 2011 05:01, alan c <aeclist@???> wrote:
> On 23/09/11 20:39, James Courtier-Dutton wrote:
>> I think it would be nice if you could use the secure boot to protect a
>> Linux install, instead of just disabling secure boot if you wish to
>> run Linux.
>
> Good strategy. Anyone know how to begin to arrange this?
> --


Not sure.
Another thought could be that UEFI is just the wrong approach. It will
just increase boot times by making the bios more complex.
I think it would be nice to have the BIOS have a very small section,
and all it could do is boot from a user writable part of on board
flash.
You could then have a very small amount of BIOS code, and the user
writable part would contain the boot menu, bzImage and initrd.
For example, I have a Samsung I9000 phone. And it does exactly what I
describe during boot. The BIOS ROM part is minute because it only has
to boot from the first sector of the flash and not much else. It does
not even properly program the chipset, it does only the minimal needed
to boot the first sector of the flash. The flash contains user written
boot loaders etc. Also the BIOS ROM on the I9000 is read only, It is a
ROM, and cannot be overwritten with anything else, so it is virus
safe. The I9000 has a secure boot mode as well.
The I9000 BIOS ROM also has a recovery mode, whereby, if you move a
jumper, it can be made to boot from USB instead of the internal FLASH.
In something as small as an I9000 phone, the jumper move is actually a
re-solder job, but for the PC platform, that could be a jumper on the
motherboard.

The whole reason before to have a BIOS that could display stuff on the
screen was because the MSDOS operating system needed it.
Now days, with the OS containing all the drivers to talk to the
graphics card directly, the BIOS does not need to do that job any
more.
I think all the BIOS interactive modes should instead be moved to the
user supplier boot loader, on zimage/initrd section.
The motherboard manufacturer would only have to supply a data file
with their motherboard, that could be interpreted by the user code to
correctly program the motherboard chipset. The existing BIOS provided
ACPI data might be enough.

The jumper on the motherboard can be electronic.
For example, on the Samsung I9000, the micro-USB connection has an
extra pin (5 pins) which is one more than the normal 4 pins for USB.
Depending on the resistor put between the 5th pin and 4th pin, it
places the phone in different modes.
So, one of these modes could the the "reprogram BIOS" mode. I.e. Only
if you have the correct spec cable plugged in, would the BIOS be
writable or a new public key be writable.

For security reasons, the only safe way to change the low level BIOS
or the base signing key is by using physical means. I.e. you have to
actually be sitting at the PC to make the changes. You need a base
point where some code is running that you can be 100% sure that it
cannot be written to by a virus.

There is a big problem though, with how to handle "public key revoke".
I.e. If the secure key written into you BIOS is compromised, how do
you replace it fast with a known good one, and your system still
continue to boot!

I think motherboard manufacturers would also favor the "minimal"
approach for BIOS, as it would make their lives easier.

--
Please post to: Hampshire@???
Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL: http://www.hantslug.org.uk
--------------------------------------------------------------