wiki/src/blueprint/more_efficient_memory_wipe.mdwn

   1 After following the steps for "[[contribute/release_process/test/erase_memory_on_shutdown]]"
   2 it turns out some patterns may survive the wipe which indicates that
   3 not all memory was wiped. One theory for this is that the new kernel
   4 loaded by kexec may allocate some buffer, which then is filled with
   5 the pattern and won't get cleared, since sdmem only wipes unallocated
   6 memory.
   7
   8 This was supposedly not a problem for some testers prior to Tails 0.8
   9 but I can reliably reproduce this problem on a machine (with 4 GB or
  10 RAM if that matters) with both Tails 0.8 and 0.7.2.
  11
  12 [[!toc levels=2]]
  13
  14 Roadmap
  15 =======
  16
  17 * wait for [[todo/hugetlb_mem_wipe]] to be fine
  18   tuned and finished.
  19
  20 Implementation ideas
  21 ====================
  22
  23 initramfs + sdmem
  24 -----------------
  25
  26 > Hi, not sure how to comment so I will just add it here. The test is
  27 > incorrect, since on a 32-bit architecture the address space of a
  28 > given process is usually limited at 3 GiB (or less, depends on the
  29 > kernel configuration). It's not easy to change the Python script to
  30 > fill all available memory (it's possible, but complex due to
  31 > kernel's OOM killer behavior), but your best bet would be to spawn
  32 > many pattern filler processes simultaneously, hoping that at least
  33 > some executions will overlap. Then, on a 4 GiB machine you will see
  34 > about 1 GiB of non-wiped memory (and on systems with > 4 GiB RAM,
  35 > with PAE enabled, you won't wipe that extra memory, too, of course).
  36 > Sorry to burst your bubble -- wiping memory is not easy, and THC's
  37 > SecureDelete package is mostly badly implemented snake oil based on
  38 > wrongly interpreted old theoretical papers. Anyway, to see whether
  39 > the 3 GiB limit has anything to do with the unwiped patterns you
  40 > have seen thus far, retry on a system with less than 3 GiB RAM. --MK
  41
  42 >> Right. Updated the [[testing
  43 >> documentation|contribute/release_process/test/erase_memory_on_shutdown]]
  44 >> accordingly. Thanks for pointing this out. --intrigeri
  45
  46 Possible fixes (180f058 + 0f1f476d) now waiting to be tested in devel branch.
  47
  48 This change is shipped in Tails 0.14 and later, and works already
  49 quite well in practice (almost always perfect wiping on PAE systems
  50 according to our tests, a bit worse on non-PAE).
  51
  52 In theory, it's supposed to work "most of the time", but it is not
  53 reliable as is:  sdmem kills itself as soon as it's refused to
  54 allocate memory, so there's no guarantee several instances of it will
  55 be allocating enough memory at the same time to ensure all memory is
  56 erased. In the worst case, this change can make the memory erasure
  57 process 32 times longer, with no efficiency improvement.
  58
  59 initramfs + custom program
  60 --------------------------
  61
  62 Using a custom memory wiping program from initramfs is mostly
  63 implemented in the `feature/hugetlb_mem_wipe` branch.
  64
  65 Linux memtest
  66 -------------
  67
  68 Better would be to imitate Liberte Linux, that recently switched to
  69 using the Linux kernel's `memtest=2` feature, which is simpler, more
  70 robust, and allows wiping more RAM. This option will be
  71 enabled in the next (> 3.1.4-1) Debian kernel.
  72
  73 => registered as a [[TODO page|todo/move_from_sdmem_to_memtest]] with
  74 actual action plans.
  75
  76 This needs to kexec a specific [[todo/amd64_kernel]] when possible to
  77 be of any use on systems with more than 1 GB of memory.
  78
  79 Testing results:
  80
  81 * a 1GB 686-pae (no NX bit) box: 2MB pattern found after wiping, 813MB
  82   after not wiping
  83 * another 1GB 686-pae box: 640MB found after not wiping, 0 after
  84   wiping
  85 * VM 64-bit PAE 4G RAM:
  86   - 3313MB found after not wiping
  87   - 0 found after wiping with memtest (64-bit kernel)
  88   - 2675MB found after wiping with memtest (686-pae kernel)
  89
  90 Dedicated operating systems
  91 ---------------------------
  92
  93 On the long run, if the Linux kernel does not wipe whatever memory
  94 pages it allocates to use for its own data structures, the kexec'd
  95 program could be a custom, dedicated to memory erasure one, instead
  96 of a regular Linux kernel + ramdisk + userspace memory erasure
  97 program. This is probably the only way to overwrite **all** memory
  98 that was used in Tails.
  99
 100 An experiment has been done on [[patching memtest86+|memtest86plus]]
 101 to do this job.
 102
 103 Another experiment with [[GRUB|grub]] is in progress.
 104
 105 Other ideas
 106 -----------
 107
 108 * in 686-pae kernel, mount a `tmpfs` and fill it (that can cover more
 109   memory than a single sdmem process in 32-bit environment); beware
 110   how the kernel currently handles out-of-memory with when using
 111   tmpfs: instead of erroring write(2) with ENOSPC, it simply kills the
 112   process. This makes it harder to implement a nice progress bar...
 113   But yeah, combination of dd, pv and a tmpfs should also be able to
 114   do a faire amount of wiping.