Alex Pennace
February 16, 2006



Modern operating systems use a portion of a computer's hard drive as additional RAM. The operating system can "page out" or "swap" portions of code or data to the hard drive, freeing up space in RAM for more code or data. With contemporary operating systems, most applications neither know nor care about this ballet; any code or data on the hard drive is brought back into RAM if the application accesses it.

Some applications, such as a web browser making a secure "https" connection to an e-commerce web site, or the GnuPG encryption suite, cannot have some of its data swapped out to the hard drive like any other bit of data. To swap out an encryption key puts that key at risk for future recovery. Even if the data on the hard drive is subsequently written over, a determined party with physical access to the drive will be able to recover that data.

In UNIX, the contemporary solution to this problem is mlock. An application using mlock can tell the operating system to not swap out a particular piece of code or data. The drawback is RAM is a precious resource; that is why swap space on the hard drive is used. Further, a rouge application can use mlock to lock a large chunk of data in RAM, starving other applications of RAM. Typical UNIX systems restrict mlock to "superuser" processes -- in other words, the mlock facility is not available to normal applications.

mcryptswap tells the operating system to ensure that if a particular piece of code or data needs to be swapped out, then the data is securely encrypted before being written to disk.


int mcryptswap(const void *addr, size_t len);


mcryptswap guarantees that the memory in the range addr to addr+len will not be written to swap "in the clear." Child processes do inherit this across a fork.


Operating systems have wide latitude in implementing mcryptswap. mcryptswap can be made to call mlock, although that defeats the purpose. On the other extreme, an operating system can encrypt just the bytes marked by mcryptswap. Most operating systems will probably encrypt each page involved, without considering sub-page ranges.

Operating systems should employ reasonable encryption algorithms and keep the encryption key in RAM.