|
|
[[!tag archived]]
|
|
|
|
|
|
After following the steps for "[[contribute/release_process/test/erase_memory_on_shutdown]]"
|
|
|
|
|
|
After following the steps for "[erase memory on shutdown](https://tails.boum.org/contribute/release_process/test/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
|
... | ... | @@ -11,12 +11,14 @@ 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.
|
|
|
|
|
|
[[!toc levels=2]]
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
|
Roadmap
|
|
|
=======
|
|
|
|
|
|
* wait for [[todo/hugetlb_mem_wipe]] to be fine
|
|
|
* wait for [hugetlb mem wipe](https://tails.boum.org/todo/hugetlb_mem_wipe) to be fine
|
|
|
tuned and finished.
|
|
|
|
|
|
Implementation ideas
|
... | ... | @@ -41,8 +43,8 @@ initramfs + sdmem |
|
|
> 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|contribute/release_process/test/erase_memory_on_shutdown]]
|
|
|
>> Right. Updated the [testing
|
|
|
>> documentation](https://tails.boum.org/contribute/release_process/test/erase_memory_on_shutdown)
|
|
|
>> accordingly. Thanks for pointing this out. --intrigeri
|
|
|
|
|
|
Possible fixes (180f058 + 0f1f476d) now waiting to be tested in devel branch.
|
... | ... | @@ -72,10 +74,10 @@ 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|todo/move_from_sdmem_to_memtest]] with
|
|
|
=> registered as a [TODO page](https://tails.boum.org/todo/move_from_sdmem_to_memtest) with
|
|
|
actual action plans.
|
|
|
|
|
|
This needs to kexec a specific [[todo/amd64_kernel]] when possible to
|
|
|
This needs to kexec a specific [amd64 kernel](https://tails.boum.org/todo/amd64_kernel) when possible to
|
|
|
be of any use on systems with more than 1 GB of memory.
|
|
|
|
|
|
Testing results:
|
... | ... | @@ -99,10 +101,10 @@ 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+|memtest86plus]]
|
|
|
An experiment has been done on [patching memtest86+](more_efficient_memory_wipe/memtest86plus)
|
|
|
to do this job.
|
|
|
|
|
|
Another experiment with [[GRUB|grub]] is in progress.
|
|
|
Another experiment with [GRUB](more_efficient_memory_wipe/grub) is in progress.
|
|
|
|
|
|
Other ideas
|
|
|
-----------
|
... | ... | @@ -114,3 +116,4 @@ Other ideas |
|
|
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.
|
|
|
|