Re: [Tails-dev] from sdmem to memtest, and testing procedure…

Delete this message

Reply to this message
Author: Maxim Kammerer
Date:  
To: intrigeri
CC: The Tails public development discussion list
Subject: Re: [Tails-dev] from sdmem to memtest, and testing procedures
Hi intrigeri,

> I got exactly the same results as anonym did, using qemu console's
> pmemsave command to get a memory dump of a 4GB VM.


When replacing an initramfs-based memwipe process with memtest, I of
course tested the functionality using pmemsave in QEMU, and found that
absolutely all RAM that I could fill before booting into the KEXEC
kernel was wiped correctly (and I checked that none of it was wiped
with memtest=0). The RAM was filled by creating as large file as
possible in UnionFS without crashing the kernel, and summing the
region sizes reported by memtest resulted in a larger value than was
accessible to memwipe process previously. More importantly, memwipe
process caused problems with some VMs and laptops (hanging in the
end), whereas memtest didn't cause any.

> 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).


I don't see any reason to assume that the regions must be contiguous,
as there is probably some address translation going on. Testing 882
MiB instead of (4 GiB - a few MiB) in your test is very strange,
however. My guess would be that it has something to do with the KEXEC
kernel configuration used.

> 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.


Of course it's not meant to do that, since it can't test the memory
taken up by the kernel itself, for instance, but in my tests with the
specialized KEXEC kernel that would be just a few MiB (6–8, I think —
don't remember right now). However, I didn't test with QEMU memory
sizes over 512 MiB, so that might be the problem. Did you experience
the same problems with memories in the ballpark of 512 MiB? I will
take a look at the memory testing code, but it would be a big surprise
if it limits itself to, e.g., the lower 1 GiB. Will also test with 1.5
GiB RAM in QEMU (that's the best I can do with my hardware).

> So it seems the Linux kernel's memtest= feature is *not* suitable, as
> is, for any kind of anti-forensics memory wiping.


I don't see any better alternative, and would favor an upstream bug
report (in case memtest is too limited) to yet another custom
solution.

Best regards,
Maxim

--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)