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 crypto<>soft crypto Good > Soft crypto<>talitos 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 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
---
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
---
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
---
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
