FIXME this process is quite complicated and should be automated using VMs

You are highly welcome to save the result of this test in test results

0. Prepare the needed tools

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

Pick one of those:

  • qemu pmemsave (pros: no initial setup)
  • virtualbox dumpguestcore (pros: no initial setup)
  • pxedump (pros: works for bare metal, possible to |grep and avoid writting the huge dump file to disk; cons: initial setup)
  • 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 0.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 cannot 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).
  • Kill fillram processes and reboot Tails when free memory is under a threshold by running:

     while [ $(free -m -o | grep Mem | sed -e 's/  */ /g' | cut -d ' ' -f 4) -ge 128 ] ; do sleep 0.1 ; done ; killall fillram ; reboot
    

    This is especially important on 486 kernels. The threshold might be fine tuned.

  • 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.