loopaes-3.2b-2.4.31_x86.dsl
Forum: The Testing Area
Topic: loopaes-3.2b-2.4.31_x86.dsl
started by: roberts
Posted by roberts on Aug. 07 2008,20:52
Thanks to WDef for:| Code Sample |
| Title: loopaes-3.2b-2.4.31_x86.dsl Description: Partition encryption with tripl frontend Version: 3.2b Authors: Jari Ruusu <jariruusu@users.sourceforge.net> Original-site: http://loop-aes.sourceforge.net/ Copying: GNU GPL -----==[ Color = red Filesize: 160K ]==----- Extension by: wdef Comments: *** ONLY FOR 2.4.31 KERNEL DSL4+ or (eg) 2.1b *** Updated + extra cipher modules (serpent, twofish, blowfish) and patched utils for the most mature of all the linux partition encryption progs. Run the wrapper from the right-click menu to update the modules. I've included "tripl", my humble cli frontend to make single or multiple encryption with loopaes easy. Change-log: 3rd version: updated to 3.2b Enabled VIA padlock hardware AES xcrypt. Updated tripl (much improved v0.56) 2nd version: tripl updated 0.3. 17 June 2007 - First version 26 June 2007 - Second version Current: 2008/08/02 - 3rd version |
Posted by WDef on Aug. 09 2008,11:00
Notes1. If anyone out there is running dsl on a recent-ish VIA processor, I'd be interested in hearing how VIA padlock hw encryption works with this extension.
Since loop-aes is already very fast with software encryption only on a fast-ish processor, one way to tell the difference might be to run the earlier version of this extension and copy a very large file to an aes128 encrypted partition, timing the write speed.
Then - umount the encrypted partition, install this extension over the earlier one (replacing the loop driver), do rmmod loop and then modprobe loop to insert the newer driver, mount the partition and then copy the same file across again, also timing the write speed.
AES encrytion should be very much faster (I think) with VIA Padlock.
On VIA hardware, loop-aes should detect and enable aes padlock support automatically.
For info see http://www.via.com.tw/en/initiatives/padlock/whyhardwareisbetter.jsp
FYI enabling this support has no effect on running this extension on other hardware.
2. Since compiling this there has been another sub-minor version release of loop-aes (v3.2c). Afaik this contains no changes of relevance to dsl unless you're using /etc/fstab to manage your loop-aes encrypted partition and you have symlinks in /etc/fstab. (NB tripl doesn't use /etc/fstab).
Posted by curaga on Aug. 09 2008,13:57
I bought some thin clients last week, some of them have Via Eden 400Mhz and some have 800Mhz. Both are supposed to have the earlier Padlock, so AES and RNG but no SHA.They should arrive next week, so I can probably test.
This is of course assuming I can get them to boot from, say usb
Posted by WDef on Aug. 09 2008,14:12
Let's hope they don't have some crippled BIOS.
Posted by curaga on Aug. 09 2008,14:46
I don't have spare laptop hard drives, so it's probably OK to use a ramdisk?
Posted by WDef on Aug. 09 2008,15:40
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.
Posted by WDef on Aug. 09 2008,15:55
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) ]
Posted by WDef on Aug. 09 2008,16:58
Ignore that last edit (above); loop module was being used by loop_serpent.Both have been rmmod'd, no problem with ramdisk.
Posted by curaga on Aug. 09 2008,18:19
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?
Posted by WDef on 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.
Posted by curaga on Aug. 10 2008,10:25
OK, so that is either a bug in 2.4 (can't be dd'd over max size in 2.6) or the current 2.4.31 kernel has a different config (mainly 100mb ram disk max size 
) than the one available.
Posted by WDef on Aug. 10 2008,12:08
Dunno. Maybe it is a bug..config has CONFIG_BLK_DEV_RAM_SIZE=4096
If cautious, I suppose you could just use a file-backed loop on dsls /ramdisk or a hard drive. You just write a file with dd and treat it as a device. But your system might freeze (or not).
I'd probably just boot the thin clients toram and use a cheap pendrive long enough for a loopaes test. .
Posted by curaga on Aug. 10 2008,17:20
But, is that .config the config of 2.4.26 or 2.4.31? No way to tell from it itself.
Posted by ^thehatsrule^ on Aug. 10 2008,17:57
See [mirror]/current/kernel/dsl.config
Posted by curaga on Aug. 19 2008,15:15
OK, they came. Boot usb quite nicely, and have in absolutely no way crippled bioses, full Award ones with even overclocking available.Well, even though they're Eden, the lower ones have Samuel 2 core which does not have Padlock. On them I get:
dd'ing a 40mb zero file: 10.13 secs
copying KNOPPIX from usb 2.0: 30.0 secs
For comparison on my P3-1Ghz laptop dd'ing 40mb took 2 secs.
I do have one higher thin client, the E90 with a double speed Eden compared to the others, which must be a Nehemiah just by the speed. I can't however boot it yet, it has a weird 4-pin power input
Posted by curaga on Sep. 06 2008,14:21
Some nice results and graphs:< http://a110wiki.de/wiki/VIA_Padlock >
Seems very damn efficient; 5x-50x speedups..
Posted by WDef on Sep. 17 2008,22:33
Nice data, thanks!The author actually has "TODO" under loop-aes, but you would expect some significant speedups as for the other partition encryption schemes I think.