Wipe RAM on Shutdown

[adrelanos]

Some stuff that Tails is having in mind.

---

package:

http://git.tails.boum.org/wiperam/tree/

---

Tails currently has a few issues with it.

https://tails.boum.org/support/known_issues/index.en.html#index23h2

On rare systems (non-PAE with big amounts of memory), Tails does not consistently erase all system memory as it should.

The other issue is an obvious one. If shutdown fails for software or hardware reasons, RAM shutdown won't be executed.

https://labs.riseup.net/code/issues/6006

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.

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

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.

And more.

---

Tails blueprint:

https://tails.boum.org/blueprint/more_efficient_memory_wipe/

---

Documentation on testing if wiping RAM works:

https://tails.boum.org/contribute/release_process/test/erase_memory_on_shutdown/

---

Test suite recipe:

https://github.com/vjrj/tails/blob/master/features/erase_memory.feature

---

Documentation:

https://tails.boum.org/doc/advanced_topics/cold_boot_attacks/index.en.html

---

Related:

• #904
• #1563

[tasket]

Good feature, but a little reminder: Some memory controllers scramble addresses and data using prng pattern, such as on Intel Core processors using ddr3. So far haven't seen anyone defeat this, so maybe some users will feel less vulnerable. See pp. 26-29 http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

[tasket]

Good feature, but a little reminder: Some memory controllers scramble addresses and data using prng pattern, such as on Intel Core processors using ddr3. So far haven't seen anyone defeat this, so maybe some users will feel less vulnerable. See pp. 26-29 http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

[awokd]

Looks like the kernel is compiled with CONFIG_XEN_SCRUB_PAGES=y. That should result in DomUs getting wiped on memory free operations, including a shutdown. Was this issue filed against the host itself? #2024 refers mostly to VMs.

[awokd]

Looks like the kernel is compiled with CONFIG_XEN_SCRUB_PAGES=y. That should result in DomUs getting wiped on memory free operations, including a shutdown. Was this issue filed against the host itself? #2024 refers mostly to VMs.