Virtual memory encryption necessity in OS X

Part of virtual memory on a computer is where the contents of RAM are written to the hard drive (as a special file called a "swapfile") to free it up for other uses. As you use your computer, the system will load programs and data into RAM, which is like having your work on the top surface of a desk. As you place more items on the top of your desk (RAM) it may get cluttered, so to keep your work flow efficient you might free some space by putting a few items into the desk's drawers (the hard drive). This is in essence how virtual memory works, and OS X makes extensive use of it to optimize RAM usage in the system and keep things running as smoothly as possible, especially if systems have relatively little RAM.

The use of virtual memory is almost vital for smooth system function, but in order to work it writes RAM contents to the drive. RAM's contents mostly are binary data from programs in their running states, but in addition to programs RAM may hold temporarily stored typed usernames, passwords, and other personal information. Therefore, if this information is then written to virtual memory, it is possible someone could scour the virtual memory data and retrieve it.

To counter this possibility, past versions of OS X have offered the option to encrypt the virtual memory files, so if the hard drive is removed then the virtual memory data on it will just be garbled information that will be of no use to anyone. This option is available in the Security system preferences, but in Lion this has changed so that secure virtual memory is on at all times. While this is logically preferable because of its enhanced security, it may seem a bit redundant to some, given Lion's support for whole-disk encryption with FileVault 2.

Unlike the original FileVault, which only encrypted the user's home directory, FileVault 2 encrypts the entire disk without the operating system being aware of it. As a result, with FileVault 2 enabled all data on the drive including OS data like virtual memory will be encrypted, which seems as if it would negate the need to enable virtual memory encryption and may have people wondering whether they should turn off virtual memory encryption for any additional performance benefit that may offer.

Recently this topic came up after a recent posting at Mac OS X Hints outlining how to manually disable virtual memory encryption in Lion by running the following command in the Terminal:

sudo defaults write /Library/Preferences/com.apple.virtualMemory DisableEncryptedSwap -boolean yes

While it may seem logical to disable virtual memory encryption and rely solely on FileVault to encrypt and protect data, unless there is a specific reason to disable encrypted virtual memory, then even with FileVault 2 enabled it is likely best to keep virtual memory encryption active. The sole reason is that if someone is able to log on to your computer or access it when the hard drive has been unlocked, then the unencrypted virtual memory can be accessed and scanned for potentially private data, simply by running a command similar to the following in the Terminal:

sudo strings - /private/var/vm/SWAPFILE > ~/info.txt

In this command, replacing SWAPFILE with the name of the system's virtual memory file (which will be something like "swapfile0" or "swapfile1") will read through it and dump text strings found in the data to a text file called "info.txt" in your home directory. This text file can then be quickly read for any relevant personal data. If FileVault 2 is enabled but you are logged in, then the virtual memory files can be read like this; however, if the virtual memory files are encrypted then even if FileVault 2 is unlocked the virtual memory files cannot be read directly like this.

Overall, even with FileVault 2, the use of additional encryption in areas like disk images, keychains, and virtual memory may still have potential security benefits, so unless there is a specific need to disable them then we recommend keeping them enabled.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.