Re: [WIP] crypto: add support for Orion5X crypto engine
* Ben Dooks | 2009-05-07 22:39:22 [+0100]:
Sorry for the late reply.
diff --git a/drivers/crypto/mv_crypto.c b/drivers/crypto/mv_crypto.c
new file mode 100644
index 000..40eb083
--- /dev/null
+++ b/drivers/crypto/mv_crypto.c
+struct req_progress {
+struct sg_mapping_iter src_sg_it;
+struct sg_mapping_iter dst_sg_it;
+
+/* src mostly */
+int this_sg_b_left;
+int src_start;
+int crypt_len;
+/* dst mostly */
+int this_dst_sg_b_left;
+int dst_start;
+int total_req_bytes;
+};
kerneldoc style documentation wouldn't go amiss here.
added
+
+static void reg_write(void __iomem *mem, u32 val)
+{
+__raw_writel(val, mem);
+}
+
+static u32 reg_read(void __iomem *mem)
+{
+return __raw_readl(mem);
+}
do you really need to wrapper these?
Not really. Initially I planned to pass the device handle instead of the
memory pointer. Also using (addr, val) looks better than the other way
around.
it is also readl/writel for pointers obtained from ioremap()
correct. So I get rid of my wrapper and switch to readl/writel
+
+#if 0
+static void hex_dump(unsigned char *info, unsigned char *buf, unsigned int
len)
+{
+printk(KERN_ERR %s\n, info);
+print_hex_dump(KERN_ERR, , DUMP_PREFIX_OFFSET,
+16, 1,
+buf, len, false);
+printk(KERN_CONT \n);
+}
+#endif
#if 0 considered bad.
I needed this a few times. Now I don't and its gone.
+
+static int m_probe(struct platform_device *pdev)
+{
+struct crypto_priv *cp;
+struct resource *res;
+int irq;
+int ret;
+
+if (cpg) {
+printk(KERN_ERR Second crypto dev?\n);
+return -EBUSY;
+}
+
+res = platform_get_resource_byname(pdev, IORESOURCE_MEM, regs);
+if (!res)
+return -ENODEV;
Returning -ENODEV is considered harmful, it will not trigger any warning
from the driver core.
I switched to ENXIO because that fits better (No such device or address)
I thing. However this also doesn't trigger any warning from the core.
What do you suggest?
--
Ben
Thanks for the review Ben.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [WIP] crypto: add support for Orion5X crypto engine
The only functional part is ecb-aes in encryption mode. The decryption seems to work in 16 byte key mode. According to the spec [1] the decryption key is different and has to be computed by the HW. Chapter 11.1.4 says, that the decryption key is computed by performing a dummy encrypt operation. This does not alter my key at all. Point 1 on the next side is referring to the AesKeyRdMode bit which must be set prior reading the key. I can't find a definition of this bit so I guess the spec is out of date here. [Ronen Shitrit] you are right, this should be fix accordingly: To decrypt a data block with a given key, the host must first load this key into the decryption engine, then start the key generation process setting AesDecMakeKey field in the AES Decryption Command Register bit to 1. At the end of the key generation process, the host reads the key registers from the Encryption engine. This decryption key is loaded by the host into the decryption key registers, to start the required description process. To read the decryption key from the encryption engine, the host must set the AesDecKeyReady field in the AES Decryption Command Register to 1 prior to the reading of the AES encryption key registers. Setting this bit enables reading of the internal key in the AES Encryption engine, which at the end of an encryption process, is the key for the decryption start point. However a SW calculation is also possible. Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes created by the expansion algorithm. So I picked the key expand routine from generic aes module and just passed the crypto test for decryption with a 16 byte long key. The other two key sizes failed. Probably the the key slots are different. Currently I have no idea what's wrong. [Ronen Shitrit] on our driver we also chose the SW calculation WA, I'm not sure why your code fail, but I can refer you to our driver as a reference, maybe you can find it as a good reference also for other issues. This is an old LSP for the 5182, but the crypto driver supposed to work on the 5182 just fine: http://downloads.buffalo.nas-central.org/KBPro_ARM9/GPL/source/linux-2.6.12_lsp.1.10.3.src.tar.gz Look for aesMakeKey API under arch/arm/mach-mv88fxx81/Soc/cesa/ I also wanted to point that the crypto engine on the 5182 passed 2 more evolutions after the 5182, which included: - Add a dedicated DMA to the crypto unit. - Support only one channel. - Fix main erratas. - Decrease SRAM size to 2K. - Add support for chain mode. Maybe you should take those into account in your design to allow support for other crypto versions in the future. If you need more details pls check the security chapter on: http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP] crypto: add support for Orion5X crypto engine
* Ronen Shitrit | 2009-03-04 18:05:12 [+0200]: However a SW calculation is also possible. Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes created by the expansion algorithm. So I picked the key expand routine from generic aes module and just passed the crypto test for decryption with a 16 byte long key. The other two key sizes failed. Probably the the key slots are different. Currently I have no idea what's wrong. [Ronen Shitrit] on our driver we also chose the SW calculation WA, I'm not sure why your code fail, but I can refer you to our driver as a reference, maybe you can find it as a good reference also for other issues. This is an old LSP for the 5182, but the crypto driver supposed to work on the 5182 just fine: http://downloads.buffalo.nas-central.org/KBPro_ARM9/GPL/source/linux-2.6.12_lsp.1.10.3.src.tar.gz Look for aesMakeKey API under arch/arm/mach-mv88fxx81/Soc/cesa/ Oh thanks a lot. I take a look on this. I also wanted to point that the crypto engine on the 5182 passed 2 more evolutions after the 5182, which included: - Add a dedicated DMA to the crypto unit. Does this mean that the crypto unit itself is now able to copy data and I don't have to use the idma for that? That sounds great. - Support only one channel. - Fix main erratas. - Decrease SRAM size to 2K. - Add support for chain mode. I can understand that, since SRAM is not that cheap and with chaining support it should not matter. Maybe you should take those into account in your design to allow support for other crypto versions in the future. If you need more details pls check the security chapter on: http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf I take a look on this as well. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP] crypto: add support for Orion5X crypto engine
Sebastian Andrzej Siewior wrote: From: Sebastian Andrzej Siewior sebast...@breakpoint.cc This is my current status of an async crypto driver for the Orion5X crypto unit. The driver uses the crypto accelerator. Is this the same security engine found in the new SheevaPlug Devkit [1]? It's has the Marvell 88F6281 (Kirkwood) processor in it. This diagram [2] shows a Security Engine, but doesn't give any detail... I found the nuts and bolts starting at page 174 of [3], with registers listed starting on page 634. thx, Jason. [1] - http://www.marvell.com/products/embedded_processors/developer/kirkwood/sheevaplug.jsp [2] - http://www.marvell.com/products/embedded_processors/kirkwood/index.jsp [3] - http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP] crypto: add support for Orion5X crypto engine
* Jason | 2009-03-03 12:49:37 [-0500]: I found the nuts and bolts starting at page 174 of [3], with registers listed starting on page 634. they look the same to me. The registers seem to be on the same spot, the description is the same from what I recall. thx, Jason. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
