On Tue, Oct 09, 2012 at 04:43:11PM +0200, intrigeri wrote: > anonym wrote (09 Oct 2012 14:17:45 GMT) : > > * feature/hugetlb_mem_wipe: > > > - With PAE kernel: > > * Patterns remaining after wipe: ~39K ≃ 600 KiB of memory > > * Time required for wipe: 2.5 seconds. > > > - With "normal" non-PAE kernel: > > * Patterns remaining after wipe: 51K ≃ 800 KiB of memory. Also, in > > this case hugetlb_mem_wipe exits at 51% progress with the > > following error: > > [...] > > * Time required for wipe: ~1 second. > > This looks very promising! > > Ague, what are the advantages of this solution, compared to the "fill > a tmpfs" idea you also had? > > (The latter would arguably have a simpler implementation, that most of > us could understand and debug, contrary to the fancy hugetlb_mem_wipe > one. Simplicity matters.)
tmpfs currently does not use huge pages, so this is doomed to be slower. Also I was a bit disappointed by how the kernel currently handles out-of-memory with when using tmpfs: instead of erroring write(2) with ENOSPC, it simply kills the 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. hugetlb_mem_wipe is written in C, but it is fairly classic C/Unix code. The most delicate part is the call to mmap(2), but it is a matter of finding the right set of options. Huge pages are a fancy Linux feature, true, but I was able to find examples easily. To sum it up: hugetlb_mem_wipe is mostly done, is very likely to be faster than other solutions and has a nice progress bar. -- Ague
pgpJGfZVotTNl.pgp
Description: PGP signature
_______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev