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 <intrigeri@???>
| 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.
