Bitfrost and dual-boot

[Jameson "Chema" Quinn]

Bitfrost protections are meaningless if they only work half of the time. If
you have a dual-boot box, how can one OS keep its protections even if the
other half is considered untrusted code? This is of course even harder
without passwords.

However, it is not impossible, with help from the firmware. Here are the
beginnings of one scheme:

An unactivated XO would have a blank space in the firmware for a key.
During activation, the OS would generate an RSA key and give it to the
firmware. It would also make any backups of that key that were necessary -
During boot, the XO would enter one of three states:
        If booting with a signed OS, it would be "key-responsive". The
firmware would, on a special system call, encrypt/decrypt one block of data
using the private key. (one block is enough to sign a hash or encrypt a
session key). This system call would be available only to root. There would
be no way, even for root, to read the key itself.
        If booting with an unsigned OS, it would be "key-unresponsive".
There would be no access to the key at all.
        If booting with a particular cheat code (hardware buttons held
down), it would be "key-permissive". The private key could be read or
written.

Also, any OS in local flash would have its core files (kernel and anything
that could execute as root) in protected flash, other OS's would not be able
to write to this flash.

Those with a developer key would be able to mark an OS on their machine as
"signed".

With this system in place, it would be possible to protect against the worst
abuses from the untrusted OS. It might still be able to read or write in the
other OS's data, but the other OS would use encryption to keep private data
from being read, and signatures to keep invalid data from leading to
escalated privileges. So the worst the rogue OS could inflict would be
dataloss; the temptations for virus writers would be minimized.

What do people think? Is this a real problem? Is my hand-waving the
beginnings of a solution, or why not?

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080528/d7f313fd/attachment.html>