Hello list,
I 've an embedded board with AMD Geode™ LX 800 Chip. I'm running Debian
Etch and Kernel 2.6.22.5. What I tried is to use dm-crypt /
cryptsetup-luks 1.0.5 with the Geode AES-Engine.
The Kernel Modul "geode_aes" is compiled and loaded successfully. The
problem is, that if the module is loaded and I try:
cryptsetup -c aes -s 256 -h sha256 luksFormat /dev/hda2
after supplying the password I get the following error:
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-plain cipher spec and verify
that /dev/hda2 contains at least 258 sectors.
Failed to write to key storage.
Command failed.
If I remove the module (rmmod geode-aes) the cryptsetup works fine.
Any suggestions are very welcome.
Kind regards,
Markus
* Markus Huehnerbein | 2007-08-29 15:50:35 [+0200]:
>I 've an embedded board with AMD Geode??? LX 800 Chip. I'm running Debian
>Etch and Kernel 2.6.22.5. What I tried is to use dm-crypt /
>cryptsetup-luks 1.0.5 with the Geode AES-Engine.
>
>The Kernel Modul "geode_aes" is compiled and loaded successfully. The
>problem is, that if the module is loaded and I try:
> cryptsetup -c aes -s 256 -h sha256 luksFormat /dev/hda2
from a quick look into the source it should work with '-s 128' or
without the -s parameter. Can you confirm this?
Sebastian
Thanks a lot! I confirm that it works with "-s 128" and also if "-s" is
skipped! But if I try to use cryptsetup with ESSIV (cryptsetup -c
aes-cbc-essiv:sha256 -y -s 128 luksFormat /dev/hda2) I get the same
error. If the "geode-aes" does not support essiv why is this task not
performed by another algorithm in the cryptoAPI?
Thanks,
Markus
Sebastian Siewior wrote:
> * Markus Huehnerbein | 2007-08-29 15:50:35 [+0200]:
>
>> I 've an embedded board with AMD Geode??? LX 800 Chip. I'm running Debian
>> Etch and Kernel 2.6.22.5. What I tried is to use dm-crypt /
>> cryptsetup-luks 1.0.5 with the Geode AES-Engine.
>>
>> The Kernel Modul "geode_aes" is compiled and loaded successfully. The
>> problem is, that if the module is loaded and I try:
>> cryptsetup -c aes -s 256 -h sha256 luksFormat /dev/hda2
>
>>from a quick look into the source it should work with '-s 128' or
> without the -s parameter. Can you confirm this?
>
> Sebastian
> -
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
* Markus Huehnerbein | 2007-08-29 16:41:57 [+0200]:
>Thanks a lot! I confirm that it works with "-s 128" and also if "-s" is
>skipped! But if I try to use cryptsetup with ESSIV (cryptsetup -c
>aes-cbc-essiv:sha256 -y -s 128 luksFormat /dev/hda2) I get the same
what about sha128 instead?
>error. If the "geode-aes" does not support essiv why is this task not
>performed by another algorithm in the cryptoAPI?
Actually it is. geode does not support keys != 128 bit. ESSIV uses as
key the output of sha256 what is 256. Check dmesg please. If my theory
is correct than you should see in dmesg or somewhere:
"Failed to set key for ESSIV cipher"
Is it?
>Thanks,
>Markus
Sebastian
Sebastian Siewior wrote:
> * Markus Huehnerbein | 2007-08-29 16:41:57 [+0200]:
>
>> Thanks a lot! I confirm that it works with "-s 128" and also if "-s" is
>> skipped! But if I try to use cryptsetup with ESSIV (cryptsetup -c
>> aes-cbc-essiv:sha256 -y -s 128 luksFormat /dev/hda2) I get the same
> what about sha128 instead?
>
>> error. If the "geode-aes" does not support essiv why is this task not
>> performed by another algorithm in the cryptoAPI?
> Actually it is. geode does not support keys != 128 bit. ESSIV uses as
> key the output of sha256 what is 256. Check dmesg please. If my theory
> is correct than you should see in dmesg or somewhere:
> "Failed to set key for ESSIV cipher"
> Is it?
Yes, again you're right, if I use a hash with 256 bit I get the
following syslog errors:
device-mapper: table: 254:1: crypt: Error initializing ESSIV hash
device-mapper: ioctl: error adding target to table
device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Unfortunately there is no support for sha128 in the Kernel so I tried
md5 as md5 also generates a 128 bit value.
Preparing the Volume with:
cryptsetup -c aes-cbc-essiv:md5 -y -s 128 luksFormat /dev/hda2
works fine ("Command successful" and no errors in the syslog) but when I
try to open the device
cryptsetup luksOpen /dev/hda2 devdmcryptluks
I get "Command failed." after entering the (correct) password. I also
tried "luksOpen" with the same arguments as "luksFormat" but the same -
"Command failed." without any trace in the syslog...
>
>> Thanks,
>> Markus
>
> Sebastian
>
Thanks again,
Markus
Sebastian Siewior <[email protected]> wrote:
>
> Actually it is. geode does not support keys != 128 bit. ESSIV uses as
> key the output of sha256 what is 256. Check dmesg please. If my theory
> is correct than you should see in dmesg or somewhere:
> "Failed to set key for ESSIV cipher"
> Is it?
Jordan, could you please confirm whether geode-aes supports
key sizes other than 128, i.e., 192 and 256?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On 30/08/07 07:55 +0800, Herbert Xu wrote:
> Sebastian Siewior <[email protected]> wrote:
> >
> > Actually it is. geode does not support keys != 128 bit. ESSIV uses as
> > key the output of sha256 what is 256. Check dmesg please. If my theory
> > is correct than you should see in dmesg or somewhere:
> > "Failed to set key for ESSIV cipher"
> > Is it?
>
> Jordan, could you please confirm whether geode-aes supports
> key sizes other than 128, i.e., 192 and 256?
No - just 128. Bad planning, I guess... :)
JOrdan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
* Markus Huehnerbein | 2007-08-29 22:29:10 [+0200]:
>Yes, again you're right, if I use a hash with 256 bit I get the
>following syslog errors:
>
>device-mapper: table: 254:1: crypt: Error initializing ESSIV hash
This error message should only come up if dm was not able to allocate
the hash in kernel so may miss SHA256 support.
>device-mapper: ioctl: error adding target to table
>device-mapper: ioctl: device doesn't appear to be in the dev hash table.
>Unfortunately there is no support for sha128 in the Kernel so I tried
well there is no sha128. I was probabaly thinking of sha1 but that one
generates 160 bit long signatures.
>md5 as md5 also generates a 128 bit value.
>
>Preparing the Volume with:
> cryptsetup -c aes-cbc-essiv:md5 -y -s 128 luksFormat /dev/hda2
>works fine ("Command successful" and no errors in the syslog) but when I
>try to open the device
> cryptsetup luksOpen /dev/hda2 devdmcryptluks
>I get "Command failed." after entering the (correct) password. I also
>tried "luksOpen" with the same arguments as "luksFormat" but the same -
>"Command failed." without any trace in the syslog...
That should have work. Does it work with the generic aes driver instead
of geode?
>Markus
Sebastian
>> device-mapper: table: 254:1: crypt: Error initializing ESSIV hash
> This error message should only come up if dm was not able to allocate
> the hash in kernel so may miss SHA256 support.
By the output of lsmod the sha256 module is loaded. But anyway, I think
in order to benefit from the geode the only way is to use md5, as there
is no other digest that provides a 128-bit value - execpt maybe tiger.
>>
>> Preparing the Volume with:
>> cryptsetup -c aes-cbc-essiv:md5 -y -s 128 luksFormat /dev/hda2
>> works fine ("Command successful" and no errors in the syslog) but when I
>> try to open the device
>> cryptsetup luksOpen /dev/hda2 devdmcryptluks
>> I get "Command failed." after entering the (correct) password. I also
>> tried "luksOpen" with the same arguments as "luksFormat" but the same -
>> "Command failed." without any trace in the syslog...
>
> That should have work. Does it work with the generic aes driver instead
> of geode?
Yes, with the generic driver luksFormat as well as luksOpen works fine.
I thought that the problem is maybe related with the use of LUKS / the
Master-Key created by the PBKDF2, so I tried cryptsetup without LUKS as
follows (with the "geode_aes" module loaded):
cryptsetup -y -c aes -h md5 -s 128 create devdmcrypt /dev/hda2
-No errors, neither in syslog nor in the output
-Checking the output of "dmsetup ls":
devdmcrypt (254, 0)
-Creating ext2 filesystem
mkfs.ext2 /dev/mapper/devdmcrypt
-Trying to mount /dev/mapper/devdmcrypt fails with "wrong fs type..."
and syslog error: "VFS: Can't find an ext2 filesystem on dev dm-0"
I'm not sure whether the problems are linked to each other or not but
maybe it could be of interesst.
--Markus
Markus Huehnerbein <[email protected]> wrote:
>
> I thought that the problem is maybe related with the use of LUKS / the
> Master-Key created by the PBKDF2, so I tried cryptsetup without LUKS as
> follows (with the "geode_aes" module loaded):
> cryptsetup -y -c aes -h md5 -s 128 create devdmcrypt /dev/hda2
> -No errors, neither in syslog nor in the output
> -Checking the output of "dmsetup ls":
> devdmcrypt (254, 0)
> -Creating ext2 filesystem
> mkfs.ext2 /dev/mapper/devdmcrypt
> -Trying to mount /dev/mapper/devdmcrypt fails with "wrong fs type..."
> and syslog error: "VFS: Can't find an ext2 filesystem on dev dm-0"
Sounds like geode_aes is just broken. Can you please check if
tcrypt with mode=10 and mode=200 work or not with the geode_aes
driver?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
> Markus Huehnerbein <[email protected]> wrote:
>> I thought that the problem is maybe related with the use of LUKS / the
>> Master-Key created by the PBKDF2, so I tried cryptsetup without LUKS as
>> follows (with the "geode_aes" module loaded):
>> cryptsetup -y -c aes -h md5 -s 128 create devdmcrypt /dev/hda2
>> -No errors, neither in syslog nor in the output
>> -Checking the output of "dmsetup ls":
>> devdmcrypt (254, 0)
>> -Creating ext2 filesystem
>> mkfs.ext2 /dev/mapper/devdmcrypt
>> -Trying to mount /dev/mapper/devdmcrypt fails with "wrong fs type..."
>> and syslog error: "VFS: Can't find an ext2 filesystem on dev dm-0"
>
> Sounds like geode_aes is just broken. Can you please check if
> tcrypt with mode=10 and mode=200 work or not with the geode_aes
> driver?
Below are the syslog entries generated by modprobe tcrypt mode=10 and
modprobe tcrypt mode=200 but I'm not sure if the geoade_aes module is
used for testing - shouldn't there be something with "...geode..." in
the syslog output? Just to ensure the module is loaded:
grep geode /proc/modules
geode_aes 4676 0 - Live 0xcf259000
crypto_algapi 9920 6 geode_aes,lrw,ecb,aes,cbc,cryptomgr, Live 0xcf223000
blkcipher 4772 4 geode_aes,lrw,ecb,cbc, Live 0xcf1ea000
--------------tcrypt mode=10-------------------->
Aug 31 14:15:58 yellowbox kernel:
Aug 31 14:15:58 yellowbox kernel: testing ecb(aes) encryption
Aug 31 14:15:58 yellowbox kernel: test 1 (128 bit key):
Aug 31 14:15:58 yellowbox kernel: 69c4e0d86a7b0430d8cdb78070b4c55a
Aug 31 14:15:58 yellowbox kernel: pass
Aug 31 14:15:58 yellowbox kernel: test 2 (192 bit key):
Aug 31 14:15:59 yellowbox kernel: setkey() failed flags=200000
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing ecb(aes) decryption
Aug 31 14:15:59 yellowbox kernel: test 1 (128 bit key):
Aug 31 14:15:59 yellowbox kernel: 00112233445566778899aabbccddeeff
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 2 (192 bit key):
Aug 31 14:15:59 yellowbox kernel: setkey() failed flags=200000
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing cbc(aes) encryption
Aug 31 14:15:59 yellowbox kernel: test 1 (128 bit key):
Aug 31 14:15:59 yellowbox kernel: e353779c1079aeb82708942dbe77181a
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 2 (128 bit key):
Aug 31 14:15:59 yellowbox kernel:
d296cd94c2cccf8a3a863028b5e1dc0a7586602d253cfff91b8266bea6d61ab1
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing cbc(aes) encryption across
pages (chunking)
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing cbc(aes) decryption
Aug 31 14:15:59 yellowbox kernel: test 1 (128 bit key):
Aug 31 14:15:59 yellowbox kernel: 53696e676c6520626c6f636b206d7367
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 2 (128 bit key):
Aug 31 14:15:59 yellowbox kernel:
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing cbc(aes) decryption across
pages (chunking)
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing lrw(aes) encryption
Aug 31 14:15:59 yellowbox kernel: test 1 (256 bit key):
Aug 31 14:15:59 yellowbox kernel: f1b273cd65a3df5fe95d489254634eb8
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 2 (256 bit key):
Aug 31 14:15:59 yellowbox kernel: 00c82bae95bbcde5274f0769b260e136
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 3 (256 bit key):
Aug 31 14:15:59 yellowbox kernel: 76322183ed8ff182f9596203690e5e01
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 4 (320 bit key):
Aug 31 14:15:59 yellowbox kernel: setkey() failed flags=200000
Aug 31 14:15:59 yellowbox kernel:
Aug 31 14:15:59 yellowbox kernel: testing lrw(aes) decryption
Aug 31 14:15:59 yellowbox kernel: test 1 (256 bit key):
Aug 31 14:15:59 yellowbox kernel: 30313233343536373839414243444546
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 2 (256 bit key):
Aug 31 14:15:59 yellowbox kernel: 30313233343536373839414243444546
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 3 (256 bit key):
Aug 31 14:15:59 yellowbox kernel: 30313233343536373839414243444546
Aug 31 14:15:59 yellowbox kernel: pass
Aug 31 14:15:59 yellowbox kernel: test 4 (320 bit key):
Aug 31 14:15:59 yellowbox kernel: setkey() failed flags=200000
--------------tcrypt mode=200-------------------->
testing speed of ecb(aes) encryption
test 0 (128 bit key, 16 byte blocks): 1 operation in 1337 cycles (16 bytes)
test 1 (128 bit key, 64 byte blocks): 1 operation in 1746 cycles (64 bytes)
test 2 (128 bit key, 256 byte blocks): 1 operation in 3334 cycles (256
bytes)
test 3 (128 bit key, 1024 byte blocks): 1 operation in 9652 cycles (1024
bytes)
test 4 (128 bit key, 8192 byte blocks): 1 operation in 71057 cycles
(8192 bytes)
test 5 (192 bit key, 16 byte blocks): setkey() failed flags=200000
testing speed of ecb(aes) decryption
test 0 (128 bit key, 16 byte blocks): 1 operation in 1323 cycles (16 bytes)
test 1 (128 bit key, 64 byte blocks): 1 operation in 1740 cycles (64 bytes)
test 2 (128 bit key, 256 byte blocks): 1 operation in 3309 cycles (256
bytes)
test 3 (128 bit key, 1024 byte blocks): 1 operation in 9700 cycles (1024
bytes)
test 4 (128 bit key, 8192 byte blocks): 1 operation in 71029 cycles
(8192 bytes)
test 5 (192 bit key, 16 byte blocks): setkey() failed flags=200000
testing speed of cbc(aes) encryption
test 0 (128 bit key, 16 byte blocks): 1 operation in 1675 cycles (16 bytes)
test 1 (128 bit key, 64 byte blocks): 1 operation in 2088 cycles (64 bytes)
test 2 (128 bit key, 256 byte blocks): 1 operation in 3652 cycles (256
bytes)
test 3 (128 bit key, 1024 byte blocks): 1 operation in 10010 cycles
(1024 bytes)
test 4 (128 bit key, 8192 byte blocks): 1 operation in 72083 cycles
(8192 bytes)
test 5 (192 bit key, 16 byte blocks): setkey() failed flags=200000
testing speed of cbc(aes) decryption
test 0 (128 bit key, 16 byte blocks): 1 operation in 1705 cycles (16 bytes)
test 1 (128 bit key, 64 byte blocks): 1 operation in 2127 cycles (64 bytes)
test 2 (128 bit key, 256 byte blocks): 1 operation in 3689 cycles (256
bytes)
test 3 (128 bit key, 1024 byte blocks): 1 operation in 10051 cycles
(1024 bytes)
test 4 (128 bit key, 8192 byte blocks): 1 operation in 72185 cycles
(8192 bytes)
test 5 (192 bit key, 16 byte blocks): setkey() failed flags=200000
testing speed of lrw(aes) encryption
test 0 (256 bit key, 16 byte blocks): 1 operation in 2335 cycles (16 bytes)
test 1 (256 bit key, 64 byte blocks): 1 operation in 4767 cycles (64 bytes)
test 2 (256 bit key, 256 byte blocks): 1 operation in 14738 cycles (256
bytes)
test 3 (256 bit key, 1024 byte blocks): 1 operation in 54381 cycles
(1024 bytes)
test 4 (256 bit key, 8192 byte blocks): 1 operation in 426181 cycles
(8192 bytes)
test 5 (320 bit key, 16 byte blocks): setkey() failed flags=200000
testing speed of lrw(aes) decryption
test 0 (256 bit key, 16 byte blocks): 1 operation in 2315 cycles (16 bytes)
test 1 (256 bit key, 64 byte blocks): 1 operation in 4768 cycles (64 bytes)
test 2 (256 bit key, 256 byte blocks): 1 operation in 14650 cycles (256
bytes)
test 3 (256 bit key, 1024 byte blocks): 1 operation in 54275 cycles
(1024 bytes)
test 4 (256 bit key, 8192 byte blocks): 1 operation in 425134 cycles
(8192 bytes)
test 5 (320 bit key, 16 byte blocks): setkey() failed flags=200000
>
> Thanks,
Thanks,
Markus
On Fri, Aug 31, 2007 at 02:40:48PM +0200, Markus Huehnerbein wrote:
>
> Below are the syslog entries generated by modprobe tcrypt mode=10 and
OK. Could you please write 4K zeros to the device with dd and
then read them back out using od -x?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> OK. Could you please write 4K zeros to the device with dd and
> then read them back out using od -x?
Hope I did it right:
dd if=/dev/zero of=/dev/mapper/devdmcrypt bs=4k count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.0353821 seconds, 116 kB/s
od -x /dev/mapper/devdmcrypt
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
15720240 ab28 c716 3349 75e2 9c3d 2bcd 01ca 5216
(...)
cheers,
Markus
* Markus Huehnerbein | 2007-08-31 14:40:48 [+0200]:
>> Sounds like geode_aes is just broken. Can you please check if
>> tcrypt with mode=10 and mode=200 work or not with the geode_aes
>> driver?
>
>Below are the syslog entries generated by modprobe tcrypt mode=10 and
>modprobe tcrypt mode=200 but I'm not sure if the geoade_aes module is
>used for testing - shouldn't there be something with "...geode..." in
>the syslog output? Just to ensure the module is loaded:
>grep geode /proc/modules
>geode_aes 4676 0 - Live 0xcf259000
>crypto_algapi 9920 6 geode_aes,lrw,ecb,aes,cbc,cryptomgr, Live 0xcf223000
>blkcipher 4772 4 geode_aes,lrw,ecb,cbc, Live 0xcf1ea000
>
>--------------tcrypt mode=10-------------------->
Hmmm. Just an idea. Could you please apply the two patches from [1]
(first 0001, than 0002) and try again? I assume that the geode needs
16byte align keys just as the encrypt/decrypt function. Please try to
create and mount the crypto partition once you patched it.
[1] http://download.breakpoint.cc/patch/
* Sebastian Siewior | 2007-08-31 20:14:32 [+0200]:
>* Markus Huehnerbein | 2007-08-31 14:40:48 [+0200]:
>
>>> Sounds like geode_aes is just broken. Can you please check if
>>> tcrypt with mode=10 and mode=200 work or not with the geode_aes
>>> driver?
>>
>>Below are the syslog entries generated by modprobe tcrypt mode=10 and
>>modprobe tcrypt mode=200 but I'm not sure if the geoade_aes module is
>>used for testing - shouldn't there be something with "...geode..." in
>>the syslog output? Just to ensure the module is loaded:
>>grep geode /proc/modules
>>geode_aes 4676 0 - Live 0xcf259000
>>crypto_algapi 9920 6 geode_aes,lrw,ecb,aes,cbc,cryptomgr, Live 0xcf223000
>>blkcipher 4772 4 geode_aes,lrw,ecb,cbc, Live 0xcf1ea000
>>
>>--------------tcrypt mode=10-------------------->
>
[stupid - ignore]
while I was showering I realized that my previous post was brainless.
Please ignore...
Sebastian