After following the steps for "erase memory on shutdown it turns out some patterns may survive the wipe which indicates that not all memory was wiped. One theory for this is that the new kernel loaded by kexec may allocate some buffer, which then is filled with the pattern and won't get cleared, since sdmem only wipes unallocated memory.

This was supposedly not a problem for some testers prior to Tails 0.8 but I can reliably reproduce this problem on a machine (with 4 GB or RAM if that matters) with both Tails 0.8 and 0.7.2.

• Roadmap
• Implementation ideas
  • initramfs + sdmem
  • initramfs + custom program
  • Linux memtest
  • Dedicated operating systems
  • Other ideas

Roadmap¶

• wait for hugetlb mem wipe (#5342) to be fine tuned and finished.

Implementation ideas¶

initramfs + sdmem¶

<blockquote>

Hi, not sure how to comment so I will just add it here. The test is incorrect, since on a 32-bit architecture the address space of a given process is usually limited at 3 GiB (or less, depends on the kernel configuration). It's not easy to change the Python script to fill all available memory (it's possible, but complex due to kernel's OOM killer behavior), but your best bet would be to spawn many pattern filler processes simultaneously, hoping that at least some executions will overlap. Then, on a 4 GiB machine you will see about 1 GiB of non-wiped memory (and on systems with > 4 GiB RAM, with PAE enabled, you won't wipe that extra memory, too, of course). Sorry to burst your bubble -- wiping memory is not easy, and THC's SecureDelete package is mostly badly implemented snake oil based on wrongly interpreted old theoretical papers. Anyway, to see whether the 3 GiB limit has anything to do with the unwiped patterns you have seen thus far, retry on a system with less than 3 GiB RAM. --MK

Right. Updated the testing documentation accordingly. Thanks for pointing this out. --intrigeri

</blockquote>

Possible fixes (180f058 + 0f1f476d) now waiting to be tested in devel branch.

This change is shipped in Tails 0.14 and later, and works already quite well in practice (almost always perfect wiping on PAE systems according to our tests, a bit worse on non-PAE).

In theory, it's supposed to work "most of the time", but it is not reliable as is: sdmem kills itself as soon as it's refused to allocate memory, so there's no guarantee several instances of it will be allocating enough memory at the same time to ensure all memory is erased. In the worst case, this change can make the memory erasure process 32 times longer, with no efficiency improvement.

initramfs + custom program¶

Using a custom memory wiping program from initramfs is mostly implemented in the feature/hugetlb_mem_wipe branch.

Linux memtest¶

Better would be to imitate Liberte Linux, that recently switched to using the Linux kernel's memtest=2 feature, which is simpler, more robust, and allows wiping more RAM. This option will be enabled in the next (> 3.1.4-1) Debian kernel.

=> registered as a TODO page (#5658) with actual action plans.

This needs to kexec a specific amd64 kernel (#5456) when possible to be of any use on systems with more than 1 GB of memory.

Testing results:

• a 1GB 686-pae (no NX bit) box: 2MB pattern found after wiping, 813MB after not wiping
• another 1GB 686-pae box: 640MB found after not wiping, 0 after wiping
• VM 64-bit PAE 4G RAM:
  • 3313MB found after not wiping
  • 0 found after wiping with memtest (64-bit kernel)
  • 2675MB found after wiping with memtest (686-pae kernel)

Dedicated operating systems¶

On the long run, if the Linux kernel does not wipe whatever memory pages it allocates to use for its own data structures, the kexec'd program could be a custom, dedicated to memory erasure one, instead of a regular Linux kernel + ramdisk + userspace memory erasure program. This is probably the only way to overwrite all memory that was used in Tails.

An experiment has been done on "patching memtest86+":./more_efficient_memory_wipe/memtest86plus.html to do this job.

Another experiment with "GRUB":./more_efficient_memory_wipe/grub.html is in progress.

Other ideas¶

• in 686-pae kernel, mount a tmpfs and fill it (that can cover more memory than a single sdmem process in 32-bit environment); beware how the kernel currently handles out-of-memory with when using tmpfs: instead of erroring write(2) with ENOSPC, it simply kills the process. This makes it harder to implement a nice progress bar... But yeah, combination of dd, pv and a tmpfs should also be able to do a faire amount of wiping.