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
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel