The Testing Area :: loopaes-3.2b-2.4.31_x86.dsl

Should be ok to encrypt a ram disk, though a spare pen drive would provide a better comparison I guess since a ram disk is going to be so fast.

I just tried it, works.

I used /dev/ram12, with aes128. This mounted an encrypted ramdisk of about 100MB size.

In my tripl script it is necessary to comment out the following to use a ram device:

Code Sample

if ! $fdisk -l | awk '/^\/dev/{print $1}'| grep -wq ${DEVICE}; then
echo "Can't find device ${DEVICE}. Is it connected?"
exit 1
fi

- since fdisk only looks for regular disks with partition tables.

EDIT: OTOH, I've just discovered I can't rmmod loop after doing this (says busy), even though there are no loop devices busy.

[ But I don't know whether this is due to having encrypted a ramdisk or to me having perhaps tainted the kernel by inserting a mismatched(?) mmpe etc module (another thread) ]

Ignore that last edit (above); loop module was being used by loop_serpent.
Both have been rmmod'd, no problem with ramdisk.

I was going to create an ext2 loop in a tmpfs ramdisk, to get around possible limitations.
Now I just want to know how did you get a 100mb ramdisk, when the devices are 4mb?

I just set the device /dev/ram12 in .triplrc. I thought these ram devices were supposed to be small also. But after running tripl -f .triplrc.ram -n and mounting with tripl -f .triplrc.ram -m, df -h showed 95mb on the (ext2) filesystem on the loop device:

Code Sample

# losetup -a
/dev/loop0: [0100]:226 (/dev/ram12) encryption=AES128 multi-key-v3

# df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 95M 13K 90M 1% /mnt/test

# du -h /mnt/test
12K /mnt/test/lost+found
13K /mnt/test

But after umounting with tripl -f .triplrc.ram -u it's back to small again:

Code Sample

df -h /dev/ram12
Filesystem Size Used Avail Use% Mounted on
/dev/root 3.0M 735K 2.2M 25% /

I think this is to do with the preparation process for making the encrypted filesystem, in which the loop device first gets overwritten with zeros using a random key in order to fill the device with encrypted junk (equivalent to shredding). This perhaps has the effect of continuing writing into ram beyond /dev/ram12's memory address range (stopping at 95mb plus a bit extra).

Experiments:

If I just set up a non-encrypted loop (no overwriting and no filesystem readable), there is no such size increase:

Code Sample

# losetup /dev/loop0 /dev/ram12
# losetup -a
df -h /dev/loop0
Filesystem Size Used Avail Use% Mounted on
/dev/root 3.0M 735K 2.2M 25% /

If I just overwrite /dev/ram12 with zeros, I get the magic size increase (and there's no loop involved):

Code Sample

dd if=/dev/zero of=/dev/ram12
dd: writing to `/dev/ram12': No space left on device
200001+0 records in
200000+0 records out
102400000 bytes transferred in 0.859401 seconds (119152753 bytes/sec)
^^^^^^^^^^

Conjecture only:

It appears from the above that /dev/ram12 is of minimum size a bit under 4mb and that overwriting with dd has the effect of writing a file over the boundary to a maximum size of 102400000 bytes (which must be preset somewhere - kernel?). The kernel however still sees a 4mb "disk" because setting up an unencrypted loop still shows the original size. If however there's an encrypted filesystem extending over the original ramdisk boundary in memory, the whole extent of the filesystem gets seen and mounted (if it's still there) regardless of how big the kernel thinks the original ramdisk is.

The way you make a ramdisk (really just a file) in the first place is to overwrite a chunk of memory with dd, so rather than make the original ramdisk bigger, I think maybe the above just wrote a bigger one over the original and then put an encrypted filesystem on there, and it starts at the same address as does /dev/ram12.

One conclusion from this is that doing loop-aes on a ramdisk like this is actually using a file-backed loop where the file happens to be in memory, and file-backed loops are bad, although they might work ok depending on the kernel version and loop driver version (can cause freezes). Seems to work with this combo.

Next Page...
original here.