Re: help for ixp4xx crypto panic
timenhhf wrote: hi, i read your mail list on net about ixp4xx_crypto panic. i'm using linux kernel 2.6.28.9, but i can't make the IXP425 NPEs work all right. the steps i've done as followed: (1) download ixp4xx-microcode_2.4.orig.tar.gz through the URL: http://packages.debian.org/zh-cn/source/sid/ixp4xx-microcode I don't think that includes the crypto microcode. You have to get that from intel. (2)tar -zxvf ixp4xx-microcode_2.4.orig.tar.gz (3)cp ./IxNpeMicrocode.h ixp4xx-microcode/npeDl You have to modify the .h to select the crypto when you have correct code (4)gcc -Wall IxNpeMicrocode.c -o IxNpeMicrocode (5)./IxNpeMicrocode, can get NPE-B and NPE-C (6)cp NPEs to /lib/firmware : cp -a NPE-* /lib/firmware/ echo /sbin/mdev /proc/sys/kernel/hotplug /sbin/mdev -s (7)set the NPE MAC address: ifconfig eth0 hw ether 00:03:05:06:07:08 (8)ifconfig eth0 192.168.1.1 netmask 255.255.255.0 after so many steps have done, i can't ping out any packet through IXP425 mainboard. could you give me some advice? thanks in advance. best regards, It would probally be best if we made ixp4xx_crytpo BUG() or WARN_ON() if it does not have a crypto compatable microcode. -- Karl -- 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: [2.6.30-rc1] device-mapper: table: 254:0: crypt: Error allocating crypto tfm
2009/4/9 Herbert Xu herb...@gondor.apana.org.au:
[...]
Yes, patch helps. Thanks
Tested-by Maciej Rutecki maciej.rute...@gmail.com
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index d5fa565..384ca8b 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -34,7 +34,7 @@ extern int __request_module(bool wait, const char *name,
...) \
#define request_module(mod...) __request_module(true, mod)
#define request_module_nowait(mod...) __request_module(false, mod)
#define try_then_request_module(x, mod...) \
- ((x) ?: (__request_module(false, mod), (x)))
+ ((x) ?: (__request_module(true, mod), (x)))
#else
static inline int request_module(const char *name, ...) { return -ENOSYS; }
static inline int request_module_nowait(const char *name, ...) { return
-ENOSYS; }
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Maciej Rutecki
http://www.maciek.unixy.pl
--
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: [2.6.30-rc1] device-mapper: table: 254:0: crypt: Error allocating crypto tfm
On Thu, Apr 09, 2009 at 03:05:51PM +0200, Patrick McHardy wrote:
It also seems to fix a netfilter problem with modules not loaded
automatically anymore.
They should still autoload, but now you need to retry the operation
manually :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ixp4xx_crypto: check firmware for crypto support
- the loaded firmware may not support crypto at all or
only support DES and 3DES but not AES or
support DES, 3DES and AES.
- in case of no crypto support of the firmware, the module load will fail.
- in case of missing AES support, the AES algorithms are not registered
and a warning is printed during module load.
Signed-off-by: Christian Hohnstaedt chohnsta...@innominate.com
---
drivers/crypto/ixp4xx_crypto.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index fdcd0ab..f72f414 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -415,6 +415,7 @@ static void crypto_done_action(unsigned long arg)
static int init_ixp_crypto(void)
{
int ret = -ENODEV;
+ u32 msg[2] = { 0, 0 };
if (! ( ~(*IXP4XX_EXP_CFG2) (IXP4XX_FEATURE_HASH |
IXP4XX_FEATURE_AES | IXP4XX_FEATURE_DES))) {
@@ -426,9 +427,35 @@ static int init_ixp_crypto(void)
return ret;
if (!npe_running(npe_c)) {
- npe_load_firmware(npe_c, npe_name(npe_c), dev);
+ ret = npe_load_firmware(npe_c, npe_name(npe_c), dev);
+ if (ret) {
+ return ret;
+ }
+ if (npe_recv_message(npe_c, msg, STATUS_MSG))
+ goto npe_error;
+ } else {
+ if (npe_send_message(npe_c, msg, STATUS_MSG))
+ goto npe_error;
+
+ if (npe_recv_message(npe_c, msg, STATUS_MSG))
+ goto npe_error;
}
+ switch ((msg[1]16) 0xff) {
+ case 3:
+ printk(KERN_WARNING Firmware of %s lacks AES support\n,
+ npe_name(npe_c));
+ support_aes = 0;
+ break;
+ case 4:
+ case 5:
+ support_aes = 1;
+ break;
+ default:
+ printk(KERN_ERR Firmware of %s lacks crypto support\n,
+ npe_name(npe_c));
+ return -ENODEV;
+ }
/* buffer_pool will also be used to sometimes store the hmac,
* so assure it is large enough
*/
@@ -457,6 +484,10 @@ static int init_ixp_crypto(void)
qmgr_enable_irq(RECV_QID);
return 0;
+
+npe_error:
+ printk(KERN_ERR %s not responding\n, npe_name(npe_c));
+ ret = -EIO;
err:
if (ctx_pool)
dma_pool_destroy(ctx_pool);
--
1.6.0.3
--
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: [PATCH] add self-tests for rfc4309(ccm(aes))
On Thursday 09 April 2009 14:52:04 Neil Horman wrote: On Thu, Apr 09, 2009 at 02:34:59PM -0400, Jarod Wilson wrote: Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail. Signed-off-by: Jarod Wilson ja...@redhat.com snip +/* + * rfc4309 says section 8 contains test vectors, only, it doesn't, and NIST + * Special Publication 800-38C's test vectors use nonce lengths our rfc4309 + * implementation doesn't support. The following are taken from fips cavs + * fax files on hand at Red Hat. + * + * nb: actual key lengths are (klen - 3), the last 3 bytes are actually + * part of the nonce which combine w/the iv, but need to be input this way. + */ RFC4309 section 8 actually says the test vectors you can use are here: http://www.ietf.org/rfc/rfc3610.txt in RFC3610 section 8. Oh, I'm dense, didn't correctly parse that 4309 was referring back to 3610 for the actual test vectors. I'll see what I can do with those... I don't think theres anything wrong with the vectors your're using below, but you may want to add the vectors from 3610 just to imrpove the testing. I think I'd drop some of the ones in the initial patch in favor of adding some from 3610, rather than simply adding more. The coverage is already pretty good, increasing the number of vectors shouldn't really be necessary, but it would definitely be nice to have vectors that are already publicly published and verified. -- Jarod Wilson ja...@redhat.com -- 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: [PATCH] add self-tests for rfc4309(ccm(aes))
On Thu, Apr 09, 2009 at 03:16:53PM -0400, Jarod Wilson wrote: On Thursday 09 April 2009 14:52:04 Neil Horman wrote: On Thu, Apr 09, 2009 at 02:34:59PM -0400, Jarod Wilson wrote: Patch is against current cryptodev-2.6 tree, successfully tested via 'modprobe tcrypt type=45'. The number of test vectors might be a bit excessive, but I tried to hit a wide range of combinations of varying key sizes, associate data lengths, input lengths and pass/fail. Signed-off-by: Jarod Wilson ja...@redhat.com snip +/* + * rfc4309 says section 8 contains test vectors, only, it doesn't, and NIST + * Special Publication 800-38C's test vectors use nonce lengths our rfc4309 + * implementation doesn't support. The following are taken from fips cavs + * fax files on hand at Red Hat. + * + * nb: actual key lengths are (klen - 3), the last 3 bytes are actually + * part of the nonce which combine w/the iv, but need to be input this way. + */ RFC4309 section 8 actually says the test vectors you can use are here: http://www.ietf.org/rfc/rfc3610.txt in RFC3610 section 8. Oh, I'm dense, didn't correctly parse that 4309 was referring back to 3610 for the actual test vectors. I'll see what I can do with those... Its easy to miss. It referrs to the RFC in an endnote by reference. I don't think theres anything wrong with the vectors your're using below, but you may want to add the vectors from 3610 just to imrpove the testing. I think I'd drop some of the ones in the initial patch in favor of adding some from 3610, rather than simply adding more. The coverage is already pretty good, increasing the number of vectors shouldn't really be necessary, but it would definitely be nice to have vectors that are already publicly published and verified. ACK to that. -- 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
