summaryrefslogtreecommitdiffstats
path: root/wiki/src/contribute/release_process/test/erase_memory_on_shutdown.mdwn
blob: 616ee1d0a7f0b3781d1bd2c86f2c3359e2df9236 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
**FIXME** this process is quite complicated and should be automated using VMs

[[!toc levels=2]]

# 0. Prepare the needed tools

Make sure the BIOS is *not* configured to "test" the memory on startup.

Pick one of those:

* [[erase_memory_on_shutdown/qemu_pmemsave]] (pros: no initial setup)
* [[erase_memory_on_shutdown/virtualbox_dumpguestcore]]
  (pros: no initial setup)
* [[erase_memory_on_shutdown/pxedump]] (pros: works for bare metal,
  possible to `|grep` and avoid writting the huge dump file to disk;
  cons: initial setup)
* [[erase_memory_on_shutdown/live_system]] (pros: works for bare metal;
  cons: storage requirements, quite more complicated to get right than
  the other methods)

# 1. Fill the RAM with a known pattern

* Run `fillram` a few times in parallel (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); as root:
  
      for i in $(seq 0 31) ; do fillram & done ; watch -n 1 free -m

* The `free` output should allow you to reboot late enough (so that
  enough memory is filled) and soon enough (so that the system is
  still reactive somehow).

# 2. Test that you can get the pattern after rebooting, if no memory wiping takes place

* Make sure your preferred memory scrapper toolkit is ready.
* Reboot from Tails using `SysRq + b`; if testing in a VM, you'd
  better be careful not rebooting your host system and proceed like
  this:
  
      echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger
  
* Dump memory and try to find the known pattern in it, e.g.:

      grep -c wipe_didnt_work tails.dump

  - you should get some integer larger than zero if the pattern was found in
    RAM, which is the expected result;
  - you should get `grep: /dev/mem: Cannot allocate memory` otherwise. In that
    case, it is **not** useful to process to the next step, there is something
    wrong in the way you tested.

# 3. Test that you can*not* get the pattern after rebooting Tails normally

* Redo step 1 (don't forget to add `debug=wipemem` to the kernel
  command-line if your memory scrapper toolkit needs it).
* Reboot Tails by running `reboot` as root.
* Make sure your preferred memory scrapper toolkit is ready (e.g.
  plug your USB scrapper stick).
* When Tails tells you you can unplug the USB stick, unplug the
  Tails stick. 
* Dump memory and try to find the known pattern in it, e.g.:

      grep -c wipe_didnt_work tails.dump

  - you should get zero if the pattern was not found in RAM, which is the
    optimal (and expected) result;
  - you should get an integer larger than zero if the pattern was found in
    RAM, which means that smem failed. However, there seems to be certain
    legit conditions which can make this happen any way. For instance, the new
    kernel loaded with kexec may allocate some buffer in the memory space
    that was filled with the pattern, and thus that space will not be wiped
    by smem. Hence a "reasonably small" number of occurances is still
    acceptible as it currently is unavoidable. For now, let us arbitrarily
    choose that up to 500 000 occurences (or around 8 MB since each pattern is
    16 bytes) are acceptable.