11/02/2011 06:02 PM, anonym:
> 11/01/2011 10:27 PM, anonym:
>
> 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
I'm unable to test this as I no longer have access to a spare x86_64
machine with 4+ GB of RAM, and won't for up to two weeks (unless I can
borrow some friends machine, we'll see). So if any one with access to
such a machine could try the following, that would be gold:
Do contribute/release_process/test/erase_memory_on_shutdown test with
the following changes:
1. Build an amd64 based lenny debian live system and install it on some
USB drive (as root):
lb config --architecture amd64 --apt-recommends false \
--distribution lenny --binary-images usb-hdd \
--binary-indices false --memtest none \
--packages-lists="minimal" --syslinux-menu vesamenu \
--initramfs=live-initramfs \
--bootappend-live "init=/bin/bash"
lb build
cat binary.img > $SECOND_USB_DRIVE
2. Instead of grep:ing /dev/mem directly in both steps 2 and 3, do this:
dd if=/dev/mem of=$DUMP bs=1K count=$RAM_SIZE_IN_KB oflag=direct
where $DUMP is some large enough storage for dumping your entire RAM
into. It could be a USB drive, but I'd recommend a fast harddrive unless
you want to wait for half an hour or more. The longer the dump takes,
the more RAM may be overwritten, so speed is crucial, actually. One
problem is that the live system built above doesn't include cryptsetup,
lvm2 and friends, so you'll need an unencrypted partition.
You may want to do:
RAM_SIZE_IN_KB=$(free -k | awk '/Mem:/ { print $2 }')
I think it should be right. The point is to get $RAM_SIZE_IN_KB exactly
right -- it should be in kilobytes of the 1024 bytes variant. The
important thing is just to get bs and count in such a way that dd reads
as much of your RAM as possible, but *NOT* more. Also, bs should be
small since dd allocates that much memory for its own buffer, and that
will overwrite RAM. oflag=direct will ensure that no cache is used,
which otherwise would start to over-write RAM for buffers.
The grep is then performed as:
grep -c wipe_didnt_work $DUMP
Everything else is identical. If this works, we should update the test
accordingly.
Cheers!
