Re: authencesn compatibility problemn between software crypto and talitos driver
Ccing Horia Geanta, he did the esn implementation for talitos. On Fri, Mar 08, 2013 at 03:27:48PM +, Chaoxing Lin wrote: 1. Can any one point me which RFC describe how exactly authencesn should work? The ESN algorithm is described in RFC 4303 IP Encapsulating Security Payload (ESP). 2. I test Ipsec with esp=aes256-sha512-esn! options and found compatibility issue between kernel software crypto and talitos driver. Talitos talitos Good Soft cryptosoft crypto Good Soft cryptotalitos link established but no traffic can pass through. 3. Looking at source code of latest stable kernel 3.8.2, I found that these two implementations don't agree on what's to be hashed in ESN case. Talitos driver is more intuitive in that assoc (SPI, SN-hi, SN-low) + IV + payload are hashed. The ESN implementation of the talitos driver looks rather scary, it just renames authenc to authencesn in talitos_probe(). The algorithm pretends to be authencesn but still does authenc, of course. authencesn has to be implemented, it is not sufficient to change the name, really. Kernel software crypto is counter-intuitive in that hsg(SPI, SN-low) + sg(IV + payload) + tsg(SN-hi are hashed. This might look counterintuitive, but that's what RFC 4303 describes for ESN if separate encryption and integrity algorithms are used. -- 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 v3 1/2] i.MX27: Add clock support for SAHARA2.
On Mon, Mar 11, 2013 at 09:19:26AM +0800, Herbert Xu wrote: On Mon, Mar 11, 2013 at 12:08:56AM +0100, Sascha Hauer wrote: On Sun, Mar 10, 2013 at 04:34:01PM +0800, Herbert Xu wrote: https://patchwork.kernel.org/patch/1817741/ So the change above becomes unnecessary Very good. Then this patch can be safely dropped. So should I take this patch or not? This clk patch, no. The sahara patch, yes, if it is fine for you. But will the second patch work fine without the first? It will work once a device is registered. The necessary clocks for it will be provided by the devicetree then. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v3 1/2] i.MX27: Add clock support for SAHARA2.
Hi, On 11 March 2013 08:42, Sascha Hauer s.ha...@pengutronix.de wrote: On Mon, Mar 11, 2013 at 09:19:26AM +0800, Herbert Xu wrote: On Mon, Mar 11, 2013 at 12:08:56AM +0100, Sascha Hauer wrote: On Sun, Mar 10, 2013 at 04:34:01PM +0800, Herbert Xu wrote: https://patchwork.kernel.org/patch/1817741/ So the change above becomes unnecessary Very good. Then this patch can be safely dropped. So should I take this patch or not? This clk patch, no. The sahara patch, yes, if it is fine for you. But will the second patch work fine without the first? It will work once a device is registered. The necessary clocks for it will be provided by the devicetree then. As Sascha stated you can safely drop this first patch: [PATCH v3 1/2] i.MX27: Add clock support for SAHARA2. And merge the second one: [PATCH v3 2/2] crypto: sahara: Add driver for SAHARA2 accelerator. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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
[PATCHv1] crypto: caam - set RDB bit in security configuration register
This change is required for post SEC-5.0 devices which have RNG4.
Setting RDB in security configuration register allows CAAM to use the
Random Data Buffer to be filled by a single request. The Random Data
Buffer is large enough for ten packets to get their IVs from a single
request. If the Random Data Buffer is not enabled, then each IV causes a
separate request, and RNG4 hardware cannot keep up resulting in lower
IPSEC throughput if random IVs are used.
Signed-off-by: Vakul Garg va...@freescale.com
---
Changes in v1: Addressed Kim Philip's comments.
(a) Limit commit message to 75 characters.
(b) Relocated code to set RDB bit in RNG4 initialisation section
drivers/crypto/caam/ctrl.c |3 +++
drivers/crypto/caam/regs.h |4 +++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index bf20dd8..79278d5 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -304,6 +304,9 @@ static int caam_probe(struct platform_device *pdev)
caam_remove(pdev);
return ret;
}
+
+ /* Enable RDB bit so that RNG works faster */
+ setbits32(topregs-ctrl.scfgr, SCFGR_RDBENABLE);
}
/* NOTE: RTIC detection ought to go here, around Si time */
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 3223fc6..cd6feda 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -252,7 +252,8 @@ struct caam_ctrl {
/* Read/Writable*/
u32 rsvd1;
u32 mcr;/* MCFG Master Config Register */
- u32 rsvd2[2];
+ u32 rsvd2;
+ u32 scfgr; /* SCFGR, Security Config Register */
/* Bus Access Configuration Section 010-11f */
/* Read/Writable*/
@@ -299,6 +300,7 @@ struct caam_ctrl {
#define MCFGR_WDFAIL 0x2000 /* DECO watchdog force-fail */
#define MCFGR_DMA_RESET0x1000
#define MCFGR_LONG_PTR 0x0001 /* Use 32-bit desc addressing */
+#define SCFGR_RDBENABLE0x0400
/* AXI read cache control */
#define MCFGR_ARCACHE_SHIFT12
--
1.7.7.6
--
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] crypto: replace kmalloc and then memcpy with kmemdup
Signed-off-by: Mihnea Dobrescu-Balaur mihne...@gmail.com
---
drivers/crypto/ux500/hash/hash_core.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/ux500/hash/hash_core.c
b/drivers/crypto/ux500/hash/hash_core.c
index 632c333..8d16d3a 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -1368,14 +1368,12 @@ static int hash_setkey(struct crypto_ahash *tfm,
/**
* Freed in final.
*/
- ctx-key = kmalloc(keylen, GFP_KERNEL);
+ ctx-key = kmemdup(key, keylen, GFP_KERNEL);
if (!ctx-key) {
pr_err(DEV_DBG_NAME [%s] Failed to allocate ctx-key
for %d\n, __func__, alg);
return -ENOMEM;
}
-
- memcpy(ctx-key, key, keylen);
ctx-keylen = keylen;
return ret;
--
1.7.10.4
--
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
[PATCHv1] crypto: caam - set RDB bit in security configuration register
This change is required for post SEC-5.0 devices which have RNG4.
Setting RDB in security configuration register allows CAAM to use the
Random Data Buffer to be filled by a single request. The Random Data
Buffer is large enough for ten packets to get their IVs from a single
request. If the Random Data Buffer is not enabled, then each IV causes a
separate request, and RNG4 hardware cannot keep up resulting in lower
IPSEC throughput if random IVs are used.
Signed-off-by: Vakul Garg va...@freescale.com
---
Changes in v1: Addressed Kim Philip's comments.
(a) Limit commit message to 75 characters.
(b) Relocated code to set RDB bit in RNG4 initialisation section
drivers/crypto/caam/ctrl.c |3 +++
drivers/crypto/caam/regs.h |4 +++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index bf20dd8..79278d5 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -304,6 +304,9 @@ static int caam_probe(struct platform_device *pdev)
caam_remove(pdev);
return ret;
}
+
+ /* Enable RDB bit so that RNG works faster */
+ setbits32(topregs-ctrl.scfgr, SCFGR_RDBENABLE);
}
/* NOTE: RTIC detection ought to go here, around Si time */
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 3223fc6..cd6feda 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -252,7 +252,8 @@ struct caam_ctrl {
/* Read/Writable*/
u32 rsvd1;
u32 mcr;/* MCFG Master Config Register */
- u32 rsvd2[2];
+ u32 rsvd2;
+ u32 scfgr; /* SCFGR, Security Config Register */
/* Bus Access Configuration Section 010-11f */
/* Read/Writable*/
@@ -299,6 +300,7 @@ struct caam_ctrl {
#define MCFGR_WDFAIL 0x2000 /* DECO watchdog force-fail */
#define MCFGR_DMA_RESET0x1000
#define MCFGR_LONG_PTR 0x0001 /* Use 32-bit desc addressing */
+#define SCFGR_RDBENABLE0x0400
/* AXI read cache control */
#define MCFGR_ARCACHE_SHIFT12
--
1.7.7.6
--
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
