<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 30.04.2009 0:53 Uhr, Peter Stuge wrote:
<blockquote cite="mid:20090429225323.655.qmail@stuge.se" type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:svn@coreboot.org">svn@coreboot.org</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">fix poweroff command on intel platforms, and add bios flash locking
example.
</pre>
</blockquote>
<pre wrap=""><!---->
Can you say something about the purpose of these functions in the
FILO bootloader? :)
I'm not so much critical as I am curious.</pre>
</blockquote>
Poweroff is just a feature for the bootloader. It started out by me
debugging why poweroff through ACPI was not working. The code serves as
an example for all the requirements, without an ACPI system running.
Plus, it's nice to not have to start an OS to do soft power off. Now
you can just say poweroff and reboot in FILO and it will do what you
expect.<br>
<br>
The flash protection code started out as a test for my SMM handler. It
is not particularly useful as is. But it allows you to decide in the
boot process whether the OS you are loading will be allowed to do flash
updates. Since FILO does the choice which OS to load, it might also
want the choice to deny flash updates; in case someone wants to add
loading of signed kernels, and disable flash updates for incorrect
signatures, or some other hypothetical security measures. Putting this
code in Linux is too late for a chain of trust, and putting it into
coreboot would mean we have to have some callback mechanism for that
feature. Both is not very appealing, so the code ended up in FILO.<br>
This code has been living in our repository for quite a while, and I
think it might be interesting to look at, as it implements a protection
scheme well known from other BIOS brands. So, now, coreboot can do it,
too. As far as I can tell, SMM protection is the only really reliable
and non-security-by-obscurity solution to prevent flash writes. GPIOs
are interesting to power-off devices in a power-managed environment,
but not for security.<br>
<br>
However, I am looking for input and feedback, which is the main reason
this went into the tree. :-)<br>
<br>
Stefan<br>
<pre class="moz-signature" cols="72">--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: <a class="moz-txt-link-abbreviated" href="mailto:info@coresystems.de">info@coresystems.de</a> • <a class="moz-txt-link-freetext" href="http://www.coresystems.de/">http://www.coresystems.de/</a>
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
</pre>
</body>
</html>