Re: sha512: make it work, undo percpu message schedule
On Fri, Jan 13, 2012 at 02:55:14AM +0300, Alexey Dobriyan wrote:
>
> Herbert, I couldn't come up with a single scenario. :-(
> But the bug is easy to reproduce.
OK, does this patch work for you?
commit 31f4e55c09c1170f8b813c14b1299b70f50db414
Author: Herbert Xu
Date: Fri Jan 13 18:06:50 2012 +1100
crypto: sha512 - Fix msg_schedule race
The percpu msg_schedule setup was unsafe as a user in a process
context can be interrupted by a softirq user which would then
scribble over the exact same work area. This was discovered by
Steffen Klassert.
This patch based on ideas from Eric Dumazet fixes this by using
two independent work areas.
Reported-by: Alexey Dobriyan
Signed-off-by: Herbert Xu
diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c
index 9ed9f60..a49c457 100644
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -11,6 +11,7 @@
*
*/
#include
+#include
#include
#include
#include
@@ -21,7 +22,9 @@
#include
#include
-static DEFINE_PER_CPU(u64[80], msg_schedule);
+#define SHA512_SCHEDULE_SIZE 80
+
+static DEFINE_PER_CPU(u64[SHA512_SCHEDULE_SIZE * 2], msg_schedule);
static inline u64 Ch(u64 x, u64 y, u64 z)
{
@@ -89,7 +92,8 @@ sha512_transform(u64 *state, const u8 *input)
u64 a, b, c, d, e, f, g, h, t1, t2;
int i;
- u64 *W = get_cpu_var(msg_schedule);
+ u64 *W = get_cpu_var(msg_schedule) +
+SHA512_SCHEDULE_SIZE * !!in_interrupt();
/* load the input */
for (i = 0; i < 16; i++)
@@ -128,7 +132,7 @@ sha512_transform(u64 *state, const u8 *input)
/* erase our data */
a = b = c = d = e = f = g = h = t1 = t2 = 0;
- memset(W, 0, sizeof(__get_cpu_var(msg_schedule)));
+ memset(W, 0, SHA512_SCHEDULE_SIZE * sizeof(*W));
put_cpu_var(msg_schedule);
}
Thanks,
--
Email: Herbert Xu
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
Re: sha512: make it work, undo percpu message schedule
On Fri, Jan 13, 2012 at 07:48:38AM +0100, Eric Dumazet wrote: > > Another solution is using two blocks, one used from interrupt context. > > static DEFINE_PER_CPU(u64[80], msg_schedule); > static DEFINE_PER_CPU(u64[80], msg_schedule_irq); > > (Like we do for SNMP mibs on !x86 arches) Yes that sounds good. Thanks Eric! -- Email: Herbert Xu 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
Re: sha512: make it work, undo percpu message schedule
Le vendredi 13 janvier 2012 à 07:22 +0100, Steffen Klassert a écrit : > On Wed, Jan 11, 2012 at 11:36:11AM +1100, Herbert Xu wrote: > > On Wed, Jan 11, 2012 at 03:00:40AM +0300, Alexey Dobriyan wrote: > > > commit f9e2bca6c22d75a289a349f869701214d63b5060 > > > aka "crypto: sha512 - Move message schedule W[80] to static percpu area" > > > created global message schedule area. > > > > > > If sha512_update will ever be entered twice, hilarity ensures. > > > > Hmm, do you know why this happens? On the face of it this shouldn't > > be possible as preemption is disabled. > > > > I did not try to reproduce, but this looks like a race of the 'local out' > and the receive packet path. On 'lokal out' bottom halves are enabled, > so could be interrupted by the NET_RX_SOFTIRQ while doing a sha512_update. > The NET_RX_SOFTIRQ could invoke sha512_update too, that would corrupt the > hash value. My guess could be checked easily by disabling the bottom halves > before the percpu value is fetched. Good catch. It can be generalized to any interrupts (soft and hard) Another solution is using two blocks, one used from interrupt context. static DEFINE_PER_CPU(u64[80], msg_schedule); static DEFINE_PER_CPU(u64[80], msg_schedule_irq); (Like we do for SNMP mibs on !x86 arches) -- 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: sha512: make it work, undo percpu message schedule
On Fri, Jan 13, 2012 at 07:22:56AM +0100, Steffen Klassert wrote: > > I did not try to reproduce, but this looks like a race of the 'local out' > and the receive packet path. On 'lokal out' bottom halves are enabled, > so could be interrupted by the NET_RX_SOFTIRQ while doing a sha512_update. > The NET_RX_SOFTIRQ could invoke sha512_update too, that would corrupt the > hash value. My guess could be checked easily by disabling the bottom halves > before the percpu value is fetched. Good point. I'll send out a patch for Alexey to test. Thanks, -- Email: Herbert Xu 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
Re: sha512: make it work, undo percpu message schedule
On Wed, Jan 11, 2012 at 11:36:11AM +1100, Herbert Xu wrote: > On Wed, Jan 11, 2012 at 03:00:40AM +0300, Alexey Dobriyan wrote: > > commit f9e2bca6c22d75a289a349f869701214d63b5060 > > aka "crypto: sha512 - Move message schedule W[80] to static percpu area" > > created global message schedule area. > > > > If sha512_update will ever be entered twice, hilarity ensures. > > Hmm, do you know why this happens? On the face of it this shouldn't > be possible as preemption is disabled. > I did not try to reproduce, but this looks like a race of the 'local out' and the receive packet path. On 'lokal out' bottom halves are enabled, so could be interrupted by the NET_RX_SOFTIRQ while doing a sha512_update. The NET_RX_SOFTIRQ could invoke sha512_update too, that would corrupt the hash value. My guess could be checked easily by disabling the bottom halves before the percpu value is fetched. -- 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] crypto: caam - fix gcc 4.6 warning
On Mon, Jan 09, 2012 at 10:27:40AM -0600, Kim Phillips wrote: > drivers/crypto/caam/ctrl.c: In function 'caam_probe': > drivers/crypto/caam/ctrl.c:49:6: warning: unused variable 'd' > [-Wunused-variable] > > Signed-off-by: Kim Phillips Both patches applied. Thanks! -- Email: Herbert Xu 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
Re: [PATCH 3/4] drivers/crypto/ixp4xx_crypto.c: convert GFP_KERNEL to GFP_ATOMIC
On Mon, Jan 09, 2012 at 10:40:49AM +0100, Julia Lawall wrote: > From: Julia Lawall > > The function is called with locks held and thus should not use GFP_KERNEL. > > The semantic patch that makes this report is available > in scripts/coccinelle/locks/call_kern.cocci. > > More information about semantic patching is available at > http://coccinelle.lip6.fr/ > > Signed-off-by: Julia Lawall Also applied. -- Email: Herbert Xu 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
Re: [PATCH v8 0/2] crypto: driver for Tegra AES hardware
On Friday 13 January 2012 11:05 AM, Herbert Xu wrote: On Fri, Dec 16, 2011 at 11:25:53AM +, Varun Wadekar wrote: The tegra crypto driver uses the tegra_chip_uid API for the RNG calculation. If one wants to build tegra-aes as a module, then tegra_chip_uid needs to be exported. Both patches applied. Thanks! Thanks Herbert. -- 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 1/1] Added CRYPTO_ALG_KERN_DRIVER_ONLY flag (4rd attempt)
On Fri, Jan 06, 2012 at 10:24:50PM +0100, Nikos Mavrogiannopoulos wrote: > This patch is the same as the previous but without the inline function. Patch applied. Thanks! -- Email: Herbert Xu 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
Re: [PATCH] crypto - serpent-sse2: change transpose_4x4 to only use integer instructions
On Tue, Dec 20, 2011 at 12:58:06PM +0200, Jussi Kivilinna wrote: > Matrix transpose macro in serpent-sse2 uses mix of SSE2 integer and SSE > floating > point instructions, which might cause performance penality on some CPUs. > > This patch replaces transpose_4x4 macro with version that uses only SSE2 > integer instructions. > > Signed-off-by: Jussi Kivilinna Patch applied. -- Email: Herbert Xu 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
Re: [PATCH 1/2] crypto: twofish-x86_64-3way - blacklist pentium4 and atom
On Tue, Dec 20, 2011 at 12:20:16PM +0200, Jussi Kivilinna wrote: > Performance of twofish-x86_64-3way on Intel Pentium 4 and Atom is lower than > of twofish-x86_64 module. So blacklist these CPUs. > > Signed-off-by: Jussi Kivilinna Both patches applied. Thanks! -- Email: Herbert Xu 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
Re: [PATCH v8 0/2] crypto: driver for Tegra AES hardware
On Fri, Dec 16, 2011 at 11:25:53AM +, Varun Wadekar wrote: > The tegra crypto driver uses the tegra_chip_uid API for the RNG > calculation. If one wants to build tegra-aes as a module, then > tegra_chip_uid needs to be exported. Both patches applied. Thanks! -- Email: Herbert Xu 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
Re: sha512: make it work, undo percpu message schedule
On Fri, Jan 13, 2012 at 02:55:14AM +0300, Alexey Dobriyan wrote: > > Herbert, I couldn't come up with a single scenario. :-( > But the bug is easy to reproduce. OK, I'll try to reproduce it here. Thanks! -- Email: Herbert Xu 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
Re: sha512: make it work, undo percpu message schedule
On Wed, Jan 11, 2012 at 11:36:11AM +1100, Herbert Xu wrote: > On Wed, Jan 11, 2012 at 03:00:40AM +0300, Alexey Dobriyan wrote: > > commit f9e2bca6c22d75a289a349f869701214d63b5060 > > aka "crypto: sha512 - Move message schedule W[80] to static percpu area" > > created global message schedule area. > > > > If sha512_update will ever be entered twice, hilarity ensures. > > Hmm, do you know why this happens? On the face of it this shouldn't > be possible as preemption is disabled. Herbert, I couldn't come up with a single scenario. :-( But the bug is easy to reproduce. -- 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 v8 2/2] crypto: driver for Tegra AES hardware
Add Herbert and David
On Friday 16 December 2011 04:55 PM, Varun Wadekar wrote:
driver supports ecb/cbc/ofb/ansi_x9.31rng modes,
128, 192 and 256-bit key sizes
Signed-off-by: Varun Wadekar
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile|1 +
drivers/crypto/tegra-aes.c | 1096
drivers/crypto/tegra-aes.h | 103 +
4 files changed, 1211 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/tegra-aes.c
create mode 100644 drivers/crypto/tegra-aes.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 6d16b4b..e707979 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -293,4 +293,15 @@ config CRYPTO_DEV_S5P
Select this to offload Samsung S5PV210 or S5PC110 from AES
algorithms execution.
+config CRYPTO_DEV_TEGRA_AES
+ tristate "Support for TEGRA AES hw engine"
+ depends on ARCH_TEGRA
+ select CRYPTO_AES
+ help
+ TEGRA processors have AES module accelerator. Select this if you
+ want to use the TEGRA module for AES algorithms.
+
+ To compile this driver as a module, choose M here: the module
+ will be called tegra-aes.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 53ea501..f3e64ea 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_CRYPTO_DEV_OMAP_SHAM) += omap-sham.o
obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o
obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
+obj-$(CONFIG_CRYPTO_DEV_TEGRA_AES) += tegra-aes.o
diff --git a/drivers/crypto/tegra-aes.c b/drivers/crypto/tegra-aes.c
new file mode 100644
index 000..422a976
--- /dev/null
+++ b/drivers/crypto/tegra-aes.c
@@ -0,0 +1,1096 @@
+/*
+ * drivers/crypto/tegra-aes.c
+ *
+ * Driver for NVIDIA Tegra AES hardware engine residing inside the
+ * Bit Stream Engine for Video (BSEV) hardware block.
+ *
+ * The programming sequence for this engine is with the help
+ * of commands which travel via a command queue residing between the
+ * CPU and the BSEV block. The BSEV engine has an internal RAM (VRAM)
+ * where the final input plaintext, keys and the IV have to be copied
+ * before starting the encrypt/decrypt operation.
+ *
+ * Copyright (c) 2010, NVIDIA Corporation.
+ *
+ * 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.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#include "tegra-aes.h"
+
+#define FLAGS_MODE_MASK0x00FF
+#define FLAGS_ENCRYPT BIT(0)
+#define FLAGS_CBC BIT(1)
+#define FLAGS_GIV BIT(2)
+#define FLAGS_RNG BIT(3)
+#define FLAGS_OFB BIT(4)
+#define FLAGS_NEW_KEY BIT(5)
+#define FLAGS_NEW_IV BIT(6)
+#define FLAGS_INIT BIT(7)
+#define FLAGS_FAST BIT(8)
+#define FLAGS_BUSY 9
+
+/*
+ * Defines AES engine Max process bytes size in one go, which takes 1 msec.
+ * AES engine spends about 176 cycles/16-bytes or 11 cycles/byte
+ * The duration CPU can use the BSE to 1 msec, then the number of available
+ * cycles of AVP/BSE is 216K. In this duration, AES can process 216/11 ~= 19KB
+ * Based on this AES_HW_DMA_BUFFER_SIZE_BYTES is configured to 16KB.
+ */
+#define AES_HW_DMA_BUFFER_SIZE_BYTES 0x4000
+
+/*
+ * The key table length is 64 bytes
+ * (This includes first upto 32 bytes key + 16 bytes original initial vector
+ * and 16 bytes updated initial vector)
+ */
+#define AES_HW_KEY_TABLE_LENGTH_BYTES 64
+
+/*
+ * The memory being used is divides as follows:
+ * 1. Key - 32 bytes
+ * 2. Original IV - 16 bytes
+ * 3. Updated IV - 16 bytes
+ * 4. Key schedule - 256 bytes
+ *
+ * 1+2+3 constitute the hw key table.
+ */
+#define AES_HW_IV_SIZE 16
+#define AES_HW_KEYSCHEDULE_LEN 256
+#define AES_IVKEY_SIZE (AES_HW_KEY_TABLE_LENGTH_BYTES + AES_HW_KEYSCHEDULE_LEN)
+
+/* Define commands required for AES operation */
+enum {
+ CMD_BLKSTARTENGINE = 0x0E,
+ CMD_DMASETUP = 0x10,
+ CMD_DM
Re: [PATCH v8 1/2] arm: tegra: export tegra_chip_uid
Add Herbert and David
On Friday 16 December 2011 04:55 PM, Varun Wadekar wrote:
From: Henning Heinold
The crypto driver will need this api to use
it in the RNG calculations. In order to build
the crypto driver as a module, tegra_chip_uid
has to be exported.
Acked-by: Olof Johansson
Signed-off-by: Henning Heinold
Signed-off-by: Varun Wadekar
---
arch/arm/mach-tegra/fuse.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/fuse.c b/arch/arm/mach-tegra/fuse.c
index 1fa26d9..ea49bd9 100644
--- a/arch/arm/mach-tegra/fuse.c
+++ b/arch/arm/mach-tegra/fuse.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
@@ -58,6 +59,7 @@ unsigned long long tegra_chip_uid(void)
hi = fuse_readl(FUSE_UID_HIGH);
return (hi<< 32ull) | lo;
}
+EXPORT_SYMBOL(tegra_chip_uid);
int tegra_sku_id(void)
{
--
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
