WDef
Group: Members
Posts: 798
Joined: Sep. 2005 |
 |
Posted: Aug. 09 2008,21:39 |
 |
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.
|
.
DSL Market ,
Great VPS hosting provided by Tektonic
