Re: [Torsion-dev] Privacy and security

[Dan Helfman]

Catatonic Porpoise wrote:
> Hello, I find the Torsion project very interesting. It is a great way to
> make use of the power 64-bit CPUs provide.
>
> About transparent persistence, though, it seems that forensic
> investigation of a hard drive is very possible, while investigating traces
> of data left in RAM is not practicable. So it seems like there are things
> I would want in RAM only, but not on the hard disk, such as my password,
> for instance.
>
> How do you plan to deal with this? Encrypt all memory saved to the hard
> disk, using a key the user must enter at boot? Or is there a better way?

Great question. With the current system, when a page of memory is 
allocated, it is set to read-only. Then when something tries to write to 
the page, the kernel traps that write, records that the page is dirty, 
and then lets the write continue. This allows the checkpointer to have a 
complete list of dirty pages to write to disk every checkpoint.

So, the way to prevent the checkpointer from writing a page to disk is 
to make it read-write to begin with, rather than read-only. This means 
that a write to the page will never be trapped, and so it'll never get 
added to the list of pages to write to disk. In fact, this is the exact 
method used for the non-persistent data within the kernel itself. The 
kernel just allocates a page read-write, and the checkpointer never 
touches it.

Now to use this read-write trick for memory containing passwords would 
require that these non-persistent pages are not part of the persistent 
virtual memory address space. If they were, then a page that is 
persistent and checkpointed might refer to it, causing problems when 
that non-persistent page isn't there anymore.

One approach would be to allow userspace applications some mechanism by 
which they can allocate read-write memory that doesn't get written to 
disk. This might be tricky, because you'd have to prevent the 
applications from referring to the memory from a persistent page, while 
still allowing them to make use of the special non-persistent page.

Another approach would be to handle passwords within the kernel. The 
kernel isn't itself persistent, and doesn't itself use persistent 
memory. So it would be fairly easy to have a call by which applications 
could ask the kernel to take care of gathering and verifying a password, 
and then the kernel could use non-persistent read-write memory in the 
process.

Thanks for the question, and let me know if you have any others.

> Thanks,
> -graue

Dan Helfman
Torsion Operating System
http://www.torsion.org/