Bitfrost and dual-boot

david at david at
Thu May 29 15:57:57 EDT 2008

On Thu, 29 May 2008, Jameson "Chema" Quinn wrote:

> I just had an IRC conversation with Benjamin Schwarz in which we talked
> about:
> He said that 3,4, and 5 have been considered more serious than 1 and 2;
> since they are impossible, there is little point doing 1 and 2. I disagreed.
> There is no way with current hardware to write-protect the NAND storage, and
> not too much space (<<512K) in the firmware storage. However, it would be
> possible to hash NAND or some subset thereof, and complain loudly on boot if
> it changed.

not really, you would have to hash NAND on every shutdown. remember 
everything you do is in thr journal on NAND, and any change (including 
things like a file timestamp, including atime) will invalidate your hash.

David Lang

> Blanking RAM on reboot, and keeping the private key in firmware
> instead of NAND are also possible.

> There is little point spending much energy on this issue until more of
> Bitfrost is in place.
> Once this becomes salient, it might be worth doing something along these
> lines. Also, it might be another good argument against dual-boot, especially
> with highly insecure OS's like Windows.
> On Thu, May 29, 2008 at 11:48 AM, Albert Cahalan <acahalan at> wrote:
>> Jameson "Chema" Quinn writes:
>>> Actually, the goals are more limited. Say you have dual-boot;
>>> OS 1 has bitfrost, OS 2 does not. Things OS 2 should not do:
>>> 1. Read private files from OS 1.
>> ...
>>> 2. By writing to OS 1's file system,
>> I do believe that, practically speaking, all of this is moot.
>> Windows uses both SD card storage and the NAND flash storage.
>> (NAND storage being what you'd hoped to protect)
> I did not hope to protect all of it. I hoped to use encryption and/or
> signatures to limit the kinds of damage that could be done.
-------------- next part --------------
Devel mailing list
Devel at

More information about the Devel mailing list