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