Re: help for swap encryption

Re: help for swap encryption

[Rik van Riel]

On Thu, 16 Aug 2001, Ted Unangst wrote:

> 1.  the data is at page->virtual, right?  that's what i want.

Doing this will make your scheme unable to work on
machines with more than 890MB of RAM.

> 2.  if a page gets written to disk, nobody will be trying to read the
> former RAM location, correct?  i was going to encrypt the ram in place.
> nobody is going to go back and try reading that RAM again, are they?

Wrong. You'll have to remove the page from the swap
cache first, possibly moving it to an encrypted
swap cache ;)

> 3.  when a page is pulled off disk, it's not automatically deleted.
> when does that occur?

It only occurs when swap space is getting full and
is done in do_swap_page().

> 4.  i don't know much about kernel programming style.  would it be
> better to store tables of data as static variables, or kmalloc a big
> chunk at some point?

Using static variables you'd make your algorithm
unable to run on multiple CPUs at the same time on
an SMP system and is cause for instant disqualification.

regards,

Rik
--
IA64: a worthy successor to i860.

http://www.surriel.com/		http://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: help for swap encryption

[Ted Unangst]

On Thu, 16 Aug 2001, Rik van Riel wrote:

> > 1.  the data is at page->virtual, right?  that's what i want.
>
> Doing this will make your scheme unable to work on
> machines with more than 890MB of RAM.

aiee!  well, i obviously don't want to encrypt the page struct.  what i'm
having trouble finding is how to access the in RAM data.  i followed the
(rw, page, dev, etc.) arguments around for a while, but i wasn't able to
see what actually got sent to disk.  how do i find out what data is
referenced by the page?

> > 2.  if a page gets written to disk, nobody will be trying to read the
> > former RAM location, correct?  i was going to encrypt the ram in place.
> > nobody is going to go back and try reading that RAM again, are they?
>
> Wrong. You'll have to remove the page from the swap
> cache first, possibly moving it to an encrypted
> swap cache ;)

yes.  i didn't account for that.


pages are 4k, right?  i'll assume so.  now, starting at the beginning,
with a simplified VM:

4k of RAM, starting at address 0x16abcdef, needs to be swapped.  so i need
to make that 4k of RAM encrypted.  or i need to encrypt it to another
address, 0x11223344, and make sure that _that_ is the data to go to disk.
it sounds like only the second choice will work without messing up the
swap cache.

problem: the page disappears into the filesystem code before being
written.  so unless i change nearly every api along the way, it looks like
every file written to disk is going to get encrypted with a random key.
that's bad.
same thing with reading it back and decrypting it.

to break the whole thing down into simple steps:
1.  page is selected for swap out.
2.  that data is encrypted.  <-- new!
3.  encrypted data goes to disk, to the same spot it would have normally.
4.  page is selected for swap in.
5.  data is read from disk.
6.  data is decrypted.  <-- new!
7.  data is copied to wherever it was supposed to go.

i'm having trouble i think because 1 & 3 and 5 & 7 as they are now, are
close to atomic operations.  as in, it's difficult to show up in between.
and the vm read/write operations are tangled up in the fs code.

well, hopefully, it won't be too much trouble to help me.  i know you're
busy.  :)  someone else?

thanks
ted




--
"If you take out the killings, Washington actually has a very very
low crime rate."
      - M. Barry, Mayor of Washington, DC


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: help for swap encryption

[Ingo Oeser]

On Thu, Aug 16, 2001 at 08:37:50PM -0700, Ted Unangst wrote:
> > > 2.  if a page gets written to disk, nobody will be trying to read the
> > > former RAM location, correct?  i was going to encrypt the ram in place.
> > > nobody is going to go back and try reading that RAM again, are they?
> >
> > Wrong. You'll have to remove the page from the swap
> > cache first, possibly moving it to an encrypted
> > swap cache ;)
> 
> yes.  i didn't account for that.
> 
> 
> pages are 4k, right?  i'll assume so.  now, starting at the beginning,
> with a simplified VM:
> to break the whole thing down into simple steps:
> 1.  page is selected for swap out.
> 2.  that data is encrypted.  <-- new!
> 3.  encrypted data goes to disk, to the same spot it would have normally.
> 4.  page is selected for swap in.
> 5.  data is read from disk.
> 6.  data is decrypted.  <-- new!
> 7.  data is copied to wherever it was supposed to go.
> 
> i'm having trouble i think because 1 & 3 and 5 & 7 as they are now, are
> close to atomic operations.  as in, it's difficult to show up in between.
> and the vm read/write operations are tangled up in the fs code.
 
No. address_space_operations is the interface.

> well, hopefully, it won't be too much trouble to help me.  i know you're
> busy.  :)  someone else?

I have spend some time thinking about this. We have the
address_space_operations for this. You can encrypt/decrypt while
your page is locked for IO and set a flag on your page. So you
decrypt or zero on readpage and encrypt on writepage.

Later you just read/write with the "inherited" function from the
swap_aops (in mm/swap_stat.c). How does that sound?

Another problem is, that you need to encrypt/decrypt IN PLACE,
which is not possible with the current cryptoapi, or have to
copy data around in PAGEs (which costs performance).

At third you may have the page present twice: One instance on disk
and one in memory. For both you have only ONE page_struct
available for flags.

If you encrypt in place, then you cannot allow two instances. You
have to require a readpage after every writepage of the same
page. But this shouldn't happen that often...

Hope that helps.

Regards

Ingo Oeser
-- 
In der Wunschphantasie vieler Mann-Typen [ist die Frau] unsigned und
operatorvertraeglich. --- Dietz Proepper in dasr
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: help for swap encryption

[Ted Unangst]

On Sat, 18 Aug 2001, Ingo Oeser wrote:

[complaint about filesystem code]
> No. address_space_operations is the interface.

Rik initially told me to come in at rw_swap_page_base().  but the real
work is done by calling brw_page(rw, page, dev, zones, block_size).  which
lives in fs/buffer.c.  but all the pages coming and going to the disk go
through here, so this is where i want to hook in.

address_space_operations:writepage -> swap_writepage -> rw_swap_page ->
rw_swap_page_base().  pretty much wrappers.  until it calls submit_bh
which i couldn't find source for.  but by now we're way out of the mm/
code, and i don't want to mess with it.


> > well, hopefully, it won't be too much trouble to help me.  i know you're
> > busy.  :)  someone else?
>
> I have spend some time thinking about this. We have the
> address_space_operations for this. You can encrypt/decrypt while
> your page is locked for IO and set a flag on your page. So you
> decrypt or zero on readpage and encrypt on writepage.
>
> Later you just read/write with the "inherited" function from the
> swap_aops (in mm/swap_stat.c). How does that sound?

rw_swap_page might be a little cleaner.  it's the "gateway" as far as i
can tell.  last function to touch the page going out, and first to touch
it coming in.

> Another problem is, that you need to encrypt/decrypt IN PLACE,
> which is not possible with the current cryptoapi, or have to
> copy data around in PAGEs (which costs performance).

i was going to use my own crypto routines, at first, just to make it work.
but this is the real problem i see coming up.  where (in memory) do we do
these operations?  in place would be easiest, but it means not keeping the
page in swap cache.  if we move it somewhere else, that somewhere else
needs RAM too.  dynamic allocation won't work because if we're swapping
out, we probably don't have much memory to spare.  so we need to
preallocate a buffer.  i fear this will lead to ungodly performance.
imagine swapping in with a buffer of X.  read X pages, then you have to
stop until they decrypt.  then read X more.

> If you encrypt in place, then you cannot allow two instances. You
> have to require a readpage after every writepage of the same
> page. But this shouldn't happen that often...

is it possible to keep pages from going in the swap cache?  in practice,
if we just sent the page to disk, aren't we going to free it anyway and
use it for some other purpose?

btw:  this should be obvious, but i'm missing it.  i have a page struct
that i pass to encrypt_page(page).  how do i access the memory with
pointers?  at some point, i need to acces the page as a big array.

thanks for help.  (please excuse VM naivity.  :))

ted




--
"The contagious people of Washington have stood firm against diversity
during this long period of increment weather."
      - M. Barry Mayor of Washington, DC

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/