11/01/2011 10:27 PM, anonym:
> 11/01/2011 07:14 PM, intrigeri:
>> Hi,
>>
>> Tails 0.9~rc1 was tagged in Git today.
>> A few of us have run most of our manual test suite against it.
>>
>> We've done everything, but:
>>
>> - test if memory erasure actually works
>
> I'll try building an amd64 based minimal live system for this, but my
> internet connection is dog slow at the moment, so I'll have to wait with
> the actual test 'till tomorrow.
So I have tried this now, and it doesn't work. I can do stuff like "grep
a /dev/mem", which finds a match very quickly, but with longer patterns,
e.g. "grep abcdefg /dev/mem" I get this behaviour:
System is responding for ~10 seconds, then keyboard input stops working,
not even magic sysrq combos work. The cursors is still blinking, though,
and I get:
BUG: soft lockup - CPU#0 stuck for 61s! [grep:2322]
twice, with a bit more than one minute break between them. Also, in
between those two, the screen goes off and on again. Weird stuff.
Maybe fmem [1] can help us out here? From the readme:
fmem 1.6.1
This module creates /dev/fmem device,
that can be used for dumping physical memory,
without limits of /dev/mem (1MB/1GB, depending on distribution)
Tested on i386 and x64, feel free to test it on
different architectures. (and send report please)
And while writing this email I noticed something really interesting,
again, from the readme:
BUGS: if you do something like # dd if=/dev/fmem of=dump
dd will never stop, even if there is no more physical RAM
on the system. This is more a feature, because Linux kernel
don't have stable API, and detection of mapped areas can be
tricky on older kernels. Because primary usage for fmem is
memory forensic, I think it is safer to specify
amount of RAM by hand.
Maybe this is what we're hitting? That wouldn't explain the lockup, I
suppose. Any way, I'll try:
dd if=/dev/fmem of=/external/usb/drive/dump bs=1MB count=$RAMSIZE
or similar later tonight and see what happens. Otherwise I'll try fmem
some other day.
[1]
http://hysteria.sk/~niekt0/fmem
