Re: [RFC PATCH] crypto: Alchemy AES engine driver

[Manuel Lauss <manuel.lauss@googlemail.com>]

Hi Sebastian,

>># modprobe alchemy-aes
>>alg: skcipher: setkey failed on test 2 for ecb-aes-alchemy: flags=200000
>># modprobe tcrypt mode=10
>>alg: skcipher: setkey failed on test 3 for cbc-aes-alchemy: flags=0
>>alg: skcipher: Failed to load transform for cbc(aes): -2
>>alg: skcipher: Failed to load transform for cbc(aes): -2
>>tcrypt: one or more tests failed!
>>FATAL: Error inserting tcrypt (/lib/modules/2.6.34-rc6-db1200-00214-g9f84af9/kernel/crypto/tcrypt.ko): Unknown symbol in module, or unknown parameter (see dmesg)
>
>>The error in "test 3 for cbc-aes-alchemy" probably comes from the inability
>>to process keys larger than 128 bits.
> You have to fix this, you have to be able to handle other keys as well.
> In case your hardware does not support it, you have to handle this in
> software. Look at the geode driver, via  or s390. All of them have
> fallbacks for. If you fail the self test, you driver will no be used
> afaik.

Ah, I wondered what those were used for.  I'll fix the driver to use them
as well.   Interestingly the algos provided are marked as tested in
/proc/crypto though.  I assumed the cryptoapi knows that the hw algo
can't handle these keylengths (it didn't even call the setkeys callback
before throwing the error) and fall back on software aes instead.


>>diff --git a/drivers/crypto/alchemy-aes.c b/drivers/crypto/alchemy-aes.c
>>new file mode 100644
>>index 0000000..14e8ace
>>--- /dev/null
>>+++ b/drivers/crypto/alchemy-aes.c
>>+static int __init alchemy_aes_load(void)
>>+{
>>+      /* FIXME: hier sollte auch noch der PRId des prozessors getestet
>>+       * werden; Au1210 (0x0503xxxx) und einige Au1300 haben lt. Daten-
>>+       * blatt keine AES engine.
>>+       */
> You German right? You should handle this in SoC code. So if you figure
> out, that you have an engine here you add the device. If you don't have
> it you don't do it and the probe call won't be called. Also the module
> won't be loaded by udev.

Hm, I'll think about it.


>>+      /* need to do 8bit accesses to memory to get correct data */
>>+      __alchemy_aes_memid = au1xxx_ddma_add_device(&alchemy_aes_mem_dbdev);
>>+      if (!__alchemy_aes_memid)
>>+              return -ENODEV;
> What does it do? You don't want to add devices here. If you need
> something additional do it in SoC code and pass it via platform_data.

The dbdma code needs templates to get the memory access width right,
this adds a template for use with the AES engine.  Every instance could
use the same template that's why it's registered in the module_init callback.
(see drivers/mmc/au1xmmc.c for instance;  yes this is a workaround for
a shortcoming of the alchemy dbdma framework).

Thanks!
        Manuel Lauss
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html