On Tue, Jun 10, 2003 at 09:44:53PM -0700, Anthony Nicholson wrote: > It's not a horrible idea. my module is implementing > encrypted swap space. when the module is installed, > [...] > exit function rather than having to type swapon/swapoff > at the command line (since users won't remember to do that > when removing the module, and bad things happen). Wouldn't it be far simpler to write an encrypting loopback device and simply put swap on -that-? Then, you would never need to change the memory characteristics from within your module.[1] Users could use the same loopback device for filesystems. Users would simply setup the loopback device, using a tool such as losetup(8), run mkswap(8) or mkfs(8) on it, run swapon(8) or mount(8), and then they are good to go. When they shut down, or wish to umount it, they do so. No extra work on your part.[2] > of course that can be done. it's just very very ugly. > swapon calls tons of other functions, all of whom I > would have to EXPORT_SYMBOL if I wanted to access > them from my module version of sys_swapon(). Oh, they aren't exported? Dang. I had hoped they'd be more or less common exported stuff.. :( I guess you could compile into the kernel a function to do similar things, and just call this function from within your module when you're ready for it. Or just work around the problem... :) [1]: How would you handle situations where memory wasn't overcommitted with the swap enabled, but disabling the swap would put memory usage above what could be handled in ram+swap? I suppose you could try flushing as much state as possible from the filesystem buffer cache, but that won't necessarily bring you back into reasonable territory.. I think it would be so much easier to just let the admin decide when to turn off swap, and do so explicitly with swapoff(8). [2]: Yeah, I've read OpenBSD's encrypted swap paper, and I think they made it far too complicated. The threat of a local user on a running system gaining access to someone else's data in the swap file is unrealistic. A user in that position can do many more things to just read another user's memory while unencrypted in memory, install trojan horses, etc. As I see it, the only threat encrypted swap is worth being used for is theft of hard drive. In that case, multiple keys matter not a whit. So, do the simple thing, and use one key. Might as well do that only once. (I think periodic rekeying of swap is also a waste of time. The expected lifetime of most cryptosystems is measured in decades; I doubt that you won't find a need to reboot at least once before then. Someone in a position to read the ciphertext off the disk on a running system is in position to do much worse things.) I hope this better explains why I think disabling swap while in the kernel isn't a good idea.. -- "Dependence on computers is apparently making a significant fraction of the population incurably stupid." -- Fritz Whittington
Attachment:
pgp00443.pgp
Description: PGP signature
