Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
Neil Horman wrote:
On Sat, May 24, 2008 at 10:06:25AM +1000, Herbert Xu wrote:
Could you document the source of these vectors in the patch
description please?
Sure, reposting
Patch to add checking of DES3 test vectors using CBC mode. FIPS-140-2
compliance mandates that any supported mode of operation must include a self
test. This satisfies that requirement for cbc(des3_ede). The included test
vector was generated by me using openssl. Key/IV was generated with the
following command:
openssl enc -des_ede_cbc -P
input and output values were generated by repeating the string Too many
secrets a few times over, truncating it to 128 bytes, and encrypting it with
openssl using the aformentioned key. Tested successfully by myself
I was wondering why you created your own test vectors. Wouldn't standardized
test vectors by NIST or ANSI be preferable?
-Adrian
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
tcrypt.c |8 +
tcrypt.h | 93
---
2 files changed, 98 insertions(+), 3 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 6beabc5..649a8e4 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1180,6 +1180,14 @@ static void do_test(void)
test_cipher(ecb(des3_ede), DECRYPT, des3_ede_dec_tv_template,
DES3_EDE_DEC_TEST_VECTORS);
+ test_cipher(cbc(des3_ede), ENCRYPT,
+ des3_ede_cbc_enc_tv_template,
+ DES3_EDE_CBC_ENC_TEST_VECTORS);
+
+ test_cipher(cbc(des3_ede), DECRYPT,
+ des3_ede_cbc_dec_tv_template,
+ DES3_EDE_CBC_DEC_TEST_VECTORS);
+
test_hash(md4, md4_tv_template, MD4_TEST_VECTORS);
test_hash(sha224, sha224_tv_template, SHA224_TEST_VECTORS);
diff --git a/crypto/tcrypt.h b/crypto/tcrypt.h
index 47bc0ec..8893733 100644
--- a/crypto/tcrypt.h
+++ b/crypto/tcrypt.h
@@ -1442,6 +1442,8 @@ static struct hash_testvec hmac_sha512_tv_template[] = {
#define DES_CBC_DEC_TEST_VECTORS 4
#define DES3_EDE_ENC_TEST_VECTORS3
#define DES3_EDE_DEC_TEST_VECTORS3
+#define DES3_EDE_CBC_ENC_TEST_VECTORS1
+#define DES3_EDE_CBC_DEC_TEST_VECTORS1
static struct cipher_testvec des_enc_tv_template[] = {
{ /* From Applied Cryptography */
@@ -1680,9 +1682,6 @@ static struct cipher_testvec des_cbc_dec_tv_template[]
= {
},
};
-/*
- * We really need some more test vectors, especially for DES3 CBC.
- */
static struct cipher_testvec des3_ede_enc_tv_template[] = {
{ /* These are from openssl */
.key= \x01\x23\x45\x67\x89\xab\xcd\xef
@@ -1745,6 +1744,94 @@ static struct cipher_testvec
des3_ede_dec_tv_template[] = {
},
};
+static struct cipher_testvec des3_ede_cbc_enc_tv_template[] = {
+ { /* Generated from openssl */
+ .key= \xE9\xC0\xFF\x2E\x76\x0B\x64\x24
+ \x44\x4D\x99\x5A\x12\xD6\x40\xC0
+ \xEA\xC2\x84\xE8\x14\x95\xDB\xE8,
+ .klen = 24,
+ .iv = \x7D\x33\x88\x93\x0F\x93\xB2\x42,
+ .input = \x6f\x54\x20\x6f\x61\x4d\x79\x6e
+ \x53\x20\x63\x65\x65\x72\x73\x74
+ \x54\x20\x6f\x6f\x4d\x20\x6e\x61
+ \x20\x79\x65\x53\x72\x63\x74\x65
+ \x20\x73\x6f\x54\x20\x6f\x61\x4d
+ \x79\x6e\x53\x20\x63\x65\x65\x72
+ \x73\x74\x54\x20\x6f\x6f\x4d\x20
+ \x6e\x61\x20\x79\x65\x53\x72\x63
+ \x74\x65\x20\x73\x6f\x54\x20\x6f
+ \x61\x4d\x79\x6e\x53\x20\x63\x65
+ \x65\x72\x73\x74\x54\x20\x6f\x6f
+ \x4d\x20\x6e\x61\x20\x79\x65\x53
+ \x72\x63\x74\x65\x20\x73\x6f\x54
+ \x20\x6f\x61\x4d\x79\x6e\x53\x20
+ \x63\x65\x65\x72\x73\x74\x54\x20
+ \x6f\x6f\x4d\x20\x6e\x61\x0a\x79,
+ .ilen = 128,
+ .result = \x15\x8d\x5d\x34\x1b\x3f\xda\xda
+ \x4f\xce\x21\x82\x12\x54\x21\x0d
+ \xb2\x36\xda\xcc\xff\xb2\xff\x79
+ \x30\xe9\x95\xf4\x52\xf6\xf1\x43
+ \xf2\x88\xe1\x1c\x42\xa1\x6a\x11
+ \xda\x8f\xbd\x94\x5e\xe5\xa8\x43
+ \xe4\x4f\xbd\x0d\x1e\x67\xa1\x89
+ \x9a\x4e\x66\x62\x50\xb3\x07\x3e
+ \xc8\xc1\x87\x3d\x96\x62\xf7\xe7
+ \x96\x15\xa8\x34\xb6\x94\x1a\x17
+ \x05\xde\x62\xd6\xd8\x73\xd6\xb4
+ \x24\x1f\x57\xb6\x80\x9a\x65\x50
+ \xa0\xee\x2f\x8b\x4c\x80\x86\xfb
+
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Hi.
On Thu, May 29, 2008 at 02:12:50PM -0500, Kim Phillips ([EMAIL PROTECTED])
wrote:
+static irqreturn_t talitos_interrupt(int irq, void *data)
+{
+ struct device *dev = data;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+
+ priv-status = in_be32(priv-reg + TALITOS_ISR);
+ priv-status_lo = in_be32(priv-reg + TALITOS_ISR_LO);
+
+ if (unlikely(priv-status ~TALITOS_ISR_CHDONE)) {
+ talitos_error((unsigned long)data);
+ /* ack */
+ out_be32(priv-reg + TALITOS_ICR, priv-status);
+ out_be32(priv-reg + TALITOS_ICR_LO, priv-status_lo);
+ }
+ else
+ {
+ /* ack */
+ out_be32(priv-reg + TALITOS_ICR, priv-status);
+ out_be32(priv-reg + TALITOS_ICR_LO, priv-status_lo);
+
+ if (likely(priv-status TALITOS_ISR_CHDONE))
+ tasklet_schedule(priv-done_task);
+ }
+
+ return (priv-status || priv-status_lo) ? IRQ_HANDLED : IRQ_NONE;
+}
Don't you want to protect against simultaneous access to register space
from different CPUs? Or it is single processor board only?
--
Evgeniy Polyakov
--
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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? -Scott -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Fri, May 30, 2008 at 02:41:17PM -0500, Scott Wood ([EMAIL PROTECTED]) wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? Yes, that register space can be assigned from non-interrupt path on different cpu. I saw spin_lock_irqsave() is used in some other places, but not in interrupt handler itself. -- Evgeniy Polyakov -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Fri, 30 May 2008 14:41:17 -0500 Scott Wood [EMAIL PROTECTED] wrote: Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. Kim -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Kim Phillips wrote: On Fri, 30 May 2008 14:41:17 -0500 Scott Wood [EMAIL PROTECTED] wrote: Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. But you don't take the spinlocks from the interrupt handler. -Scott -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
Kim Phillips wrote: On Fri, 30 May 2008 15:19:43 -0500 Scott Wood [EMAIL PROTECTED] wrote: Kim Phillips wrote: On Fri, 30 May 2008 14:41:17 -0500 Scott Wood [EMAIL PROTECTED] wrote: Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. But you don't take the spinlocks from the interrupt handler. why can't fetch fifo registers be written the same time the ISR is being accessed? I don't know -- you brought them up. My question was whether there's anything that the ISR touches that is also touched by non-ISR code. -Scott -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Fri, 30 May 2008 15:19:43 -0500 Scott Wood [EMAIL PROTECTED] wrote: Kim Phillips wrote: On Fri, 30 May 2008 14:41:17 -0500 Scott Wood [EMAIL PROTECTED] wrote: Kim Phillips wrote: On Fri, 30 May 2008 22:09:04 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: Don't you want to protect against simultaneous access to register space from different CPUs? Or it is single processor board only? Doesn't linux mask the IRQ line for the interrupt currently being serviced, and on all processors? Yes. Could there be interference from non-interrupt driver code on another cpu (or interrupted code), though? not that I can see - the fetch fifo register writes are protected with per-channel spinlocks. But you don't take the spinlocks from the interrupt handler. why can't fetch fifo registers be written the same time the ISR is being accessed? Kim -- 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
Re: [PATCH 2/2] talitos: Freescale integrated security engine (SEC) driver
On Sat, 31 May 2008 01:12:08 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 03:48:20PM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: sorry, by ISR I meant interrupt status registers. but I can't tell where the suspected simultaneous accesses are. Evgeniy, can you point out the register accesses you're talking about? priv-status is accessed from tasklets, although readonly, but that rises a red flag... Also callback invocation tasklet drops the lock around ok, I see what you are saying now; if a channel gets done during talitos_done processing, it'll trigger an interrupt and reset priv-status, leaving the tasklet in the dark as to which channel has done status, depending on how many channel dones it has already processed. I think the only solution here is to call flush_channel on each channel, regardless of the bits in the interrupt status - I'll send out a patch shortly. callback, during that time cached status and priv itself (and tail like in two simultaneous flushes) could change (or not?) I think you're talking about a different 'status' here; flush_channel's local 'status' doesn't resemble priv-status bits in any way, it looks at the descriptor header writeback bits for done status, on a per descriptor basis. It forwards this descriptor done vs. error status to the callback. priv itself won't change; it's uniquely associated to the device. Kim -- 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
Re: [PATCH] tcrypt: add self test for des3_ebe cipher operating in cbc mode
On Fri, May 30, 2008 at 07:26:38PM +0200, Adrian-Ken Rüegsegger wrote:
I was wondering why you created your own test vectors. Wouldn't standardized
test vectors by NIST or ANSI be preferable?
If you could post a patch with those that would be very much
appreciated. Thanks!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
[PATCH 2/2 v2] talitos: Freescale integrated security engine (SEC) driver
Add support for the SEC available on a wide range of PowerQUICC devices,
e.g. MPC8349E, MPC8548E.
this initial version supports authenc(hmac(sha1),cbc(aes)) for use with IPsec.
Signed-off-by: Kim Phillips [EMAIL PROTECTED]
---
removed priv-status hw interrupt status assignment. Done tasklet now
checks all channels unconditionally.
drivers/crypto/Kconfig | 15 +
drivers/crypto/Makefile |1 +
drivers/crypto/talitos.c | 1367 ++
drivers/crypto/talitos.h | 191 +++
4 files changed, 1574 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/talitos.c
create mode 100644 drivers/crypto/talitos.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 43b71b6..98d96df 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -174,4 +174,19 @@ config CRYPTO_DEV_HIFN_795X_RNG
Select this option if you want to enable the random number generator
on the HIFN 795x crypto adapters.
+config CRYPTO_DEV_TALITOS
+ tristate Talitos Freescale Security Engine (SEC)
+ select CRYPTO_ALGAPI
+ select CRYPTO_AUTHENC
+ depends on FSL_SOC
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC)
+ to offload cryptographic algorithm computation.
+
+ The Freescale SEC is present on PowerQUICC 'E' processors, such
+ as the MPC8349E and MPC8548E.
+
+ To compile this driver as a module, choose M here: the module
+ will be called talitos.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c0327f0..d29d2cd 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
new file mode 100644
index 000..cf2e6f3
--- /dev/null
+++ b/drivers/crypto/talitos.c
@@ -0,0 +1,1367 @@
+/*
+ * talitos - Freescale Integrated Security Engine (SEC) device driver
+ *
+ * Copyright (c) 2008 Freescale Semiconductor, Inc.
+ *
+ * Scatterlist Crypto API glue code copied from files with the following:
+ * Copyright (c) 2006-2007 Herbert Xu [EMAIL PROTECTED]
+ *
+ * Crypto algorithm registration code copied from hifn driver:
+ * 2007+ Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mod_devicetable.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/crypto.h
+#include linux/hw_random.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/spinlock.h
+#include linux/rtnetlink.h
+
+#include crypto/algapi.h
+#include crypto/aes.h
+#include crypto/sha.h
+#include crypto/aead.h
+#include crypto/authenc.h
+
+#include talitos.h
+
+#define TALITOS_TIMEOUT 10
+#define TALITOS_MAX_DATA_LEN 65535
+
+#define DESC_TYPE(desc_hdr) ((be32_to_cpu(desc_hdr) 3) 0x1f)
+#define PRIMARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) 28) 0xf)
+#define SECONDARY_EU(desc_hdr) ((be32_to_cpu(desc_hdr) 16) 0xf)
+
+/* descriptor pointer entry */
+struct talitos_ptr {
+ __be16 len; /* length */
+ u8 j_extent;/* jump to sg link table and/or extent */
+ u8 eptr;/* extended address */
+ __be32 ptr; /* address */
+};
+
+/* descriptor */
+struct talitos_desc {
+ __be32 hdr; /* header high bits */
+ __be32 hdr_lo; /* header low bits */
+ struct talitos_ptr ptr[7]; /* ptr/len pair array */
+};
+
+/**
+ * talitos_request - descriptor submission request
+ * @desc: descriptor pointer (kernel virtual)
+ * @dma_desc: descriptor's physical bus address
+ * @callback: whom to call when descriptor processing is done
+ * @context: caller context (optional)
+ */
+struct talitos_request {
+ struct talitos_desc *desc;
+ dma_addr_t dma_desc;
+ void (*callback) (struct device *dev, struct talitos_desc *desc,
+ void *context,
