Forum: The Testing Area
started by: roberts
Posted by roberts on Aug. 07 2008,20:52Thanks to WDef for:
Posted by WDef on Aug. 09 2008,11:00Notes
1. 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:57I 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:12Let's hope they don't have some crippled BIOS.
Posted by curaga on Aug. 09 2008,14:46I don't have spare laptop hard drives, so it's probably OK to use a ramdisk?
Posted by WDef on Aug. 09 2008,15:40Should 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:55I 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:
- 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:58Ignore 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:19I 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:39I 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:
But after umounting with tripl -f .triplrc.ram -u it's back to small again:
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).
If I just set up a non-encrypted loop (no overwriting and no filesystem readable), there is no such size increase:
If I just overwrite /dev/ram12 with zeros, I get the magic size increase (and there's no loop involved):
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:25OK, 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:08Dunno. 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:20But, 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:57See [mirror]/current/kernel/dsl.config
Posted by curaga on Aug. 19 2008,15:15OK, 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:21Some 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:33Nice 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.