* Re: help for swap encryption [not found] <Pine.GSO.4.31.0108161312050.29454-100000@cardinal0.Stanford.EDU> @ 2001-08-17 2:09 ` Rik van Riel 2001-08-17 3:37 ` Ted Unangst 0 siblings, 1 reply; 4+ messages in thread From: Rik van Riel @ 2001-08-17 2:09 UTC (permalink / raw) To: Ted Unangst; +Cc: linux-mm 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: help for swap encryption 2001-08-17 2:09 ` help for swap encryption Rik van Riel @ 2001-08-17 3:37 ` Ted Unangst 2001-08-18 17:53 ` Ingo Oeser 0 siblings, 1 reply; 4+ messages in thread From: Ted Unangst @ 2001-08-17 3:37 UTC (permalink / raw) To: Rik van Riel; +Cc: linux-mm 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: help for swap encryption 2001-08-17 3:37 ` Ted Unangst @ 2001-08-18 17:53 ` Ingo Oeser 2001-08-18 22:22 ` Ted Unangst 0 siblings, 1 reply; 4+ messages in thread From: Ingo Oeser @ 2001-08-18 17:53 UTC (permalink / raw) To: Ted Unangst; +Cc: linux-mm 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: help for swap encryption 2001-08-18 17:53 ` Ingo Oeser @ 2001-08-18 22:22 ` Ted Unangst 0 siblings, 0 replies; 4+ messages in thread From: Ted Unangst @ 2001-08-18 22:22 UTC (permalink / raw) To: Ingo Oeser; +Cc: linux-mm 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/ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-08-18 22:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.GSO.4.31.0108161312050.29454-100000@cardinal0.Stanford.EDU>
2001-08-17 2:09 ` help for swap encryption Rik van Riel
2001-08-17 3:37 ` Ted Unangst
2001-08-18 17:53 ` Ingo Oeser
2001-08-18 22:22 ` Ted Unangst
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox