Robert Bihlmeyer <[EMAIL PROTECTED]> writes: > > A better approach is to simply encrypt pages that are swapped out > > (either all swap, or configurable per user or per process). > > That incurs significant overhead. Of the 76 processes running on this > box right now, only two need that level of security at the moment. > These are served fine with mlock(), IMHO.
This is perhaps not the best place for this discussion, but let me expand a little. My main problem with the mlock approach is that it assumes sensitive data is a special case. Keys, passwords etc need protection (and can be protected using mlock(), assuming that (i) the system allows it, and (ii) that you're willing to sacrifice physical memory for it), and that the normal case for all data is that it is just fine to write it to permanent storage. I don't have any perfect real life example, but consider this story, some of whose details are actually true: I get a log file from a client's Roxen server, to help track down some SSL-related problem. The file was generated using -DSSL3_DEBUG, which by design writes information to the log that is equivalent of the server's private host key. The log is from a real server, so its not just a test key. The client trusts me not to misuse it. Now, the client should be using pgp for sending the file to me, and I should encrypt it onto some encrypted file system, or at least a filesystem that's not backed up and which implements some reasonably secure delete operation. The intention is that I'll work with the file as long as I need it, and when the case is closed, I'll throw it away. An attacker breaking into my system later won't get the client's key. But what do I do with this log? I probably want to open it in emacs. I may want to process it with tools like grep. I don't expect grep to have an option for using mlock:ed i/o buffers (and I wouldn't expect a user to know how to enable the mlock option of all his tools). The file is 100 megabytes large, so having emacs mlock its buffer wouldn't be an option even if emacs supported that. Besides, I don't have root privileges, so I can't use mlock anyway. I don't think mlock is a solution, in this and many other cases. I also think it is quite hard to get mlock:ing right in the few programs that support it (for instance, you have to ensure that the secret data is never put into variables that are allocated on the stack (unless you mlock the stack; I have no idea if that's reasonable in practice). Encrypting the swap, on the other hand, is easy (from the user's point of view) and robust. I'd enable that feature, either for my shell, or I'll ask the root to do it system wide) before decrypting the secret data, and then this particular problem goes away. You're right that it causes some significant overhead, both in cpu and memory (as Niels Provos' paper points out, while an encrypted page is being written to disk, the clear text page should still be available in memory, so we need one *additional* page for the encrypted version). mlock also causes some memory overhead, as less physical memory is left to other processes, but perhaps that overhead is smaller. If I understand things correctly, each Hurd process can use it's own default pager, so if encrypted swap is implemented, it should be fairly easy to make it configurable per process. Regards, /Niels PS. I'm not trying to argue that mlock shouldn't be implemented on the Hurd. I just want to encourage you to also consider encrypting the swap, as that's at least a little closer to the Right Thing.
