Hi, (Cc'ing someone who's with Liberté Linux: we've found the memtest= idea in their source code; therefore, they may be interested in learning it may not work as well as they expect.)
> anonym wrote (23 Dec 2011 15:41:09 GMT) : >> For tests 2 and 3 (release_process/test/erase_memory_on_shutdown) >> I rebooted to a 64-bit lenny (so CONFIG_STRICT_DEVMEM is disabled), >> and got hundreds of millions of hits in *both* tests :( (although >> test 3 had distinctively less hits than test 2). Not good. I got exactly the same results as anonym did, using qemu console's pmemsave command to get a memory dump of a 4GB VM. According to the kexec'd kernel output, memtest does 3 passes as planned (0x00, 0xff, 0x00); very well, *but* the memory ranges that are reported to be "tested" are: 0000010000 - 000009c000 000009f000 - 000009f400 0000100000 - 0001000000 00014b4049 - 00017fb000 00017fc000 - 00377fe000 Not only these intervals are not contiguous one to each other, but the greatest address (0x00377fe000) is smaller than 1GiB, which is significantly smaller than the 4GiB of memory assigned to the VM (I'm assuming these sizes are expressed in bytes). This is no wonder anymore once I had a look to the kernel source for this function: it seems it's simply not meant to test every single bit of memory. So, I think this explains very well: - why our tests with memtest enabled find significantly less canaries than our tests without any kind of memory wiping; - why anonym's >800 split ranges experiment display much more hits that earlier ones. So it seems the Linux kernel's memtest= feature is *not* suitable, as is, for any kind of anti-forensics memory wiping. Cheers, -- intrigeri <[email protected]> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | We're dreaming of something else. | Something more clandestine, something happier. _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
