It occurred to me that sensitive data can be leaked to the swap and the way SSDs store data makes it difficult to erase the data. Creating a swap partition was encouraged back in the days(idk if Anaconda still warns you if you don’t have a swap in the system). I don’t bother having a swap partition in my beefy PC build because from my experience, if your system craves swap you’re screwed anyway and do something about it. Granted, you still benefit from having a swap because the dormant region of the memory can be swapped no matter how much memory you have.
The problem is that I use laptops now. Laptops don’t come with a lot of memory and I resort to swapon when I have to do some heavy stuff. Then, it worries me: the swap is on SSD. Once data is written on a SSD, it’s really difficult to securely erase it.
I’ve got an idea: how about we borrow this idea from how SSDs do ATA secure erase? How about a systemd service(or a subsystem if you will) that sets up an encrypted swap for single use? SSDs are given random AES keys when manufactured and use them to encrypt the blocks. When you send the secure erase ATA command, the SSD simply just generates a new key and zero out the bitmap. This is how SSDs “lose” data without actually zeroing the whole thing. I think we can do the same thing with the swaps. Set up a new encrypted partition with dmcrypt on boot with randomly generated key(yes, we’re risking the low-entropy factor here), which stays in memory only. When rebooting the system, just detach the dm partition and poof! The data in the swap lost forever.
You can’t use SSDs if you’re worried about security anyways. But using swaps(which I think still encouraged) inadvertently fools security-aware users. I mean, how many of devs know how to mlock() and memset() the private keys and guarantee that they’re never optimised away? What about web browsers that don’t provide such mechanism?
Obviously, someone already thought about this. But no one seemed to have felt the need to organise this as a systemd service. Or I might have missed something. Please let me know before I go make this service script and create a request ticket!
By default fedora does not use a physical swap now, and zram became default with release 33. Swap can be seen and managed with zramctl. Since that is a virtual swap space a reboot wipes it out totally.
I remember reading about a setup where the swap partition was encrypted by luks and a new encryption key was generated for every boot. This way you could not even access old swap data if you managed to extract the encryption key from the running system. Not sure how this works with hibernation though.
Thanks. I knew the existence of zram but totally forgot about it.
The fact that zramctl exists and “swapctl” doesn’t tells me that not many people need physical swaps. I don’t like the idea of zram because you’re still sacrificing memory. The size of zram partition can be unpredictable, too. There’s no need to worry about all this when you use good old physical swap?
You just repeated my question. I was asking if anyone automated the whole process in a neat systemd unit.
Most Linux running on modern PCs can’t hibernate anyways because of EFI secure boot.
The size of the zram is not unpredictable. It is configured to use (now) by default 8 GB, and actually can store much more than that as what is stored is compressed. I have foregone the physical swap since 33 was released, and even with 8 G of zram on a system with 16 GB ram have never seen an impact on operation. I hardly ever see swap used and if it is the amount is tiny.
On my newest system, which currently is running 32G RAM this is what zramctl shows.
$ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 8G 13.5M 4.5M 7.9M 12 [SWAP]
13.5 M of swap data is compressed and stored as 4.5 M space used. With overhead the total actually used is 7.9 M.
IIUC, it does not actually dedicate that space to swap since it is dynamic and actually available to the system until needed for swap.
The configuration file is at /usr/lib/systemd/zram-generator.conf.
What I meant by unpredictable is exactly what you described.
Say I’ve got 1GB of RAM available on the system and a 0.5GB swap. I wanna start a process that will take about 1.2GB of memory. With the traditional swap, I can safely assume that the excess amount of 0.2GB will be swapped and there will be about 0.3GB of virtual space left.
With zram involved, I can’t make guesses like this. I’ll never know how much RAM I can fit more before I run out of vm because the compression ratio is an unknown factor. zram is a good alternative but we still need physical swaps.