* Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Herbert Xu @ 2013-05-28 7:42 UTC (permalink / raw)
To: Joel A Fernandes; +Cc: linux-crypto, linux-omap, khilman, Mark A. Greer
In-Reply-To: <1368500867-7737-1-git-send-email-joelagnel@ti.com>
On Tue, May 14, 2013 at 03:07:47AM +0000, Joel A Fernandes wrote:
> Calling runtime PM API for every block causes serious perf hit to
> crypto operations that are done on a long buffer.
> As crypto is performed on a page boundary, encrypting large buffers can
> cause a series of crypto operations divided by page. The runtime PM API
> is also called those many times.
>
> We call runtime_pm_get_sync only at beginning on the session (cra_init)
> and runtime_pm_put at the end. This result in upto a 50% speedup as below.
> This doesn't make the driver to keep the system awake as runtime get/put
> is only called during a crypto session which completes usually quickly.
>
> Before:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
> Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
> Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
>
> After:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
> Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
> Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s
>
> While at it, also drop enter and exit pr_debugs, in related code. tracers
> can be used for that.
>
> Tested on a Beaglebone (AM335x SoC) board.
>
> Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
I like your patch but it doesn't apply against the current cryptodev
tree.
Please rebase and repost.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
From: Herbert Xu @ 2013-05-28 5:53 UTC (permalink / raw)
To: Tim Chen; +Cc: Jussi Kivilinna, linux-crypto, Julian Wollrath, David S. Miller
In-Reply-To: <1369269124.27102.356.camel@schen9-DESK>
On Wed, May 22, 2013 at 05:32:04PM -0700, Tim Chen wrote:
> On Tue, 2013-05-21 at 17:09 +0300, Jussi Kivilinna wrote:
> > The _XFER stack element size was set too small, 8 bytes, when it needs to be
> > 16 bytes. As _XFER is the last stack element used by these implementations,
> > the 16 byte stores with 'movdqa' corrupt the stack where the value of register
> > %r12 is temporarily stored. As these implementations align the stack pointer
> > to 16 bytes, this corruption did not happen every time.
> >
> > Patch corrects this issue.
>
> Thanks for catching and fixing the issue.
>
> Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Patch applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Crypto Fixes for 3.10
From: Herbert Xu @ 2013-05-28 5:52 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20130328082841.GA7425@gondor.apana.org.au>
Hi Linus:
This push fixes a crash in the new sha256_ssse3 driver as well as
a DMA setup/teardown bug in caam.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
Horia Geanta (1):
crypto: caam - fix inconsistent assoc dma mapping direction
Jussi Kivilinna (1):
crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
arch/x86/crypto/sha256-avx-asm.S | 2 +-
arch/x86/crypto/sha256-ssse3-asm.S | 2 +-
drivers/crypto/caam/caamalg.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Oops on 3.10-rc1 related to ssh256_ssse3
From: Matt @ 2013-05-26 15:11 UTC (permalink / raw)
To: Jussi Kivilinna >; +Cc: linux-crypto, Julian Wollrath
>Appears to be stack corruption caused by sha256_transform_ssse3. >Does attached
>patch help?
>
>-Jussi
Hi Jussi, Julian,
Hi Crypto-List,
yes, the attached patch let me boot the kernel and there don't seem to
be any more additional issues or messages so far
Please mark it for inclusion in 3.10-rc3 or at least final 3.10
Thanks & Kind Regards
Matt
(Re-sending in plain text mode due to mailing list rejecting html-mails)
^ permalink raw reply
* Re: [PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
From: Linus Walleij @ 2013-05-24 11:16 UTC (permalink / raw)
To: Lee Jones, devicetree-discuss@lists.ozlabs.org, Rob Herring
Cc: Herbert Xu, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR, linux-crypto@vger.kernel.org
In-Reply-To: <20130524083231.GQ22683@gmail.com>
On Fri, May 24, 2013 at 10:32 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Fri, 24 May 2013, Linus Walleij wrote:
>> On Thu, May 16, 2013 at 1:27 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>
>> > By providing an OF match table with a suitable compatible string, we
>> > can ensure the ux500-crypt driver is probed by supplying an associated
>> > DT node in a given platform's Device Tree.
>> >
>> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> > Cc: linux-crypto@vger.kernel.org
>> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>>
>> Herbert, can I have your ACK on patch 5 & 6 in this series to take it
>> through the ARM SoC tree?
>
> Right, there are no bindings, so they don't need a document.
Surely the requirement that the node must have <reg>,
<irqs> and <regulator> for the driver to even probe is a
binding?
The fact that the drivers/of/* core on Linux will auto-populate
platform devices with those properties is a pure Linux
pecularity, and the bindings are there for OS independence.
Whether we need to document it for such standard things
is another thing, hopefully Rob or someone can answer that?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
From: Lee Jones @ 2013-05-24 8:32 UTC (permalink / raw)
To: Linus Walleij
Cc: Herbert Xu, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR, linux-crypto@vger.kernel.org
In-Reply-To: <CACRpkdZHT0g_Agtug6jC3rU+DYKOpmwqZ9eQAkRGRw5Kj0wW4A@mail.gmail.com>
On Fri, 24 May 2013, Linus Walleij wrote:
> On Thu, May 16, 2013 at 1:27 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > By providing an OF match table with a suitable compatible string, we
> > can ensure the ux500-crypt driver is probed by supplying an associated
> > DT node in a given platform's Device Tree.
> >
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: linux-crypto@vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Herbert, can I have your ACK on patch 5 & 6 in this series to take it
> through the ARM SoC tree?
Right, there are no bindings, so they don't need a document.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
From: Linus Walleij @ 2013-05-24 6:26 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR, Herbert Xu, linux-crypto@vger.kernel.org
In-Reply-To: <1368703646-26418-6-git-send-email-lee.jones@linaro.org>
On Thu, May 16, 2013 at 1:27 PM, Lee Jones <lee.jones@linaro.org> wrote:
> By providing an OF match table with a suitable compatible string, we
> can ensure the ux500-crypt driver is probed by supplying an associated
> DT node in a given platform's Device Tree.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: linux-crypto@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/crypto/ux500/cryp/cryp_core.c | 6 ++++++
W00t! No binding document?
OK I guess it's just reg, irq ... but still it's compulsory,
right?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
From: Herbert Xu @ 2013-05-24 6:21 UTC (permalink / raw)
To: Linus Walleij
Cc: Lee Jones, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR, linux-crypto@vger.kernel.org
In-Reply-To: <CACRpkdZHT0g_Agtug6jC3rU+DYKOpmwqZ9eQAkRGRw5Kj0wW4A@mail.gmail.com>
On Fri, May 24, 2013 at 08:20:38AM +0200, Linus Walleij wrote:
> On Thu, May 16, 2013 at 1:27 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > By providing an OF match table with a suitable compatible string, we
> > can ensure the ux500-crypt driver is probed by supplying an associated
> > DT node in a given platform's Device Tree.
> >
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: linux-crypto@vger.kernel.org
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Herbert, can I have your ACK on patch 5 & 6 in this series to take it
> through the ARM SoC tree?
Sure,
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
From: Linus Walleij @ 2013-05-24 6:20 UTC (permalink / raw)
To: Lee Jones, Herbert Xu
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR, linux-crypto@vger.kernel.org
In-Reply-To: <1368703646-26418-6-git-send-email-lee.jones@linaro.org>
On Thu, May 16, 2013 at 1:27 PM, Lee Jones <lee.jones@linaro.org> wrote:
> By providing an OF match table with a suitable compatible string, we
> can ensure the ux500-crypt driver is probed by supplying an associated
> DT node in a given platform's Device Tree.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: linux-crypto@vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Herbert, can I have your ACK on patch 5 & 6 in this series to take it
through the ARM SoC tree?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Stephan Mueller @ 2013-05-23 9:59 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <20130522203441.79c2f22f@tauon>
Hi Sandy,
> On Wed, 22 May 2013 13:40:04 -0400
> Sandy Harris <sandyinchina@gmail.com> wrote:
>
[...]
> >
> > >> > What I'm against is relying only on solutions such as HAVEGE or
> > >> > replacing /dev/random with something scheme that only relies on
> > >> > CPU timing and ignores interrupt timing.
> > >>
> > >> My question is how to incorporate some of that into /dev/random.
> > >> At one point, timing info was used along with other stuff. Some
> > >> of that got deleted later, What is the current state? Should we
> > >> add more?
> > >
> > > Again, I would like to suggest that we look beyond a central
> > > entropy collector like /dev/random. I would like to suggest to
> > > consider decentralizing the collection of entropy.
> >
> > I'm with Ted on this one.
>
> When you want to consider the jitter RNG for /dev/random, it should be
> used as a seed source similar to the add_*_randomness functions. I
> could implement a suggestion if that is the wish. For example, such a
> seed source could be triggered if the entropy estimator of the
> input_pool falls below some threshold. The jitter RNG could be used to
> top the entropy off to some level above another threshold.
Please see a possible integration of the CPU Jitter RNG
into /dev/random as follows. The patch does not contain the
jitterentropy-base.c, jitterentropy.h and jitterentropy-base-kernel.h
from the tarball available at http://www.chronox.de.
This patch would only use the CPU Jitter RNG if there is no more
entropy in the entropy pool. Thus, the CPU Jitter RNG is only used as a
fallback.
The patch is tested with 3.9.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
diff -urNp linux-3.9.orig/drivers/char/Makefile linux-3.9/drivers/char/Makefile
--- linux-3.9.orig/drivers/char/Makefile 2013-05-22 20:55:58.547094987 +0200
+++ linux-3.9/drivers/char/Makefile 2013-05-22 22:11:32.975008931 +0200
@@ -2,7 +2,7 @@
# Makefile for the kernel character device drivers.
#
-obj-y += mem.o random.o
+obj-y += mem.o random.o jitterentropy-base.o
obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o
obj-y += misc.o
obj-$(CONFIG_ATARI_DSP56K) += dsp56k.o
diff -urNp linux-3.9.orig/drivers/char/random.c linux-3.9/drivers/char/random.c
--- linux-3.9.orig/drivers/char/random.c 2013-05-22 20:55:58.675094985 +0200
+++ linux-3.9/drivers/char/random.c 2013-05-23 11:26:25.214103807 +0200
@@ -269,6 +269,8 @@
#define CREATE_TRACE_POINTS
#include <trace/events/random.h>
+#include "jitterentropy.h"
+
/*
* Configuration information
*/
@@ -435,6 +437,8 @@ struct entropy_store {
unsigned int initialized:1;
bool last_data_init;
__u8 last_data[EXTRACT_SIZE];
+ int jent_enable;
+ struct rand_data entropy_collector;
};
static __u32 input_pool_data[INPUT_POOL_WORDS];
@@ -446,7 +450,8 @@ static struct entropy_store input_pool =
.name = "input",
.limit = 1,
.lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
- .pool = input_pool_data
+ .pool = input_pool_data,
+ .jent_enable = -1
};
static struct entropy_store blocking_pool = {
@@ -455,7 +460,8 @@ static struct entropy_store blocking_poo
.limit = 1,
.pull = &input_pool,
.lock = __SPIN_LOCK_UNLOCKED(blocking_pool.lock),
- .pool = blocking_pool_data
+ .pool = blocking_pool_data,
+ .jent_enable = -1
};
static struct entropy_store nonblocking_pool = {
@@ -463,7 +469,8 @@ static struct entropy_store nonblocking_
.name = "nonblocking",
.pull = &input_pool,
.lock = __SPIN_LOCK_UNLOCKED(nonblocking_pool.lock),
- .pool = nonblocking_pool_data
+ .pool = nonblocking_pool_data,
+ .jent_enable = -1
};
static __u32 const twist_table[8] = {
@@ -633,6 +640,47 @@ struct timer_rand_state {
unsigned dont_count_entropy:1;
};
+/* lock of the entropy_store must already been taken */
+void add_jent_randomness(struct entropy_store *r)
+{
+#define JENTBLOCKSIZE 8 /* the most efficient use of the CPU jitter RNG is a block
+ aligned invocation. The block size of the CPU jitter RNG
+ is 8 bytes */
+ char rand[JENTBLOCKSIZE];
+ int ret = 0;
+
+ /* the initialization process determines that we cannot use the
+ * CPU Jitter RNG */
+ if(!r->jent_enable)
+ return;
+ memset(rand, 0, JENTBLOCKSIZE);
+ if(-1 == r->jent_enable)
+ {
+ /* we are uninitialized, try to initialize */
+ if(jent_entropy_init())
+ {
+ /* there is no CPU Jitter, disable the entropy collector */
+ r->jent_enable = 0;
+ return;
+ }
+ /* we do not use jent_entropy_collector_alloc as we are in early
+ * boot */
+ memset(&r->entropy_collector, 0, sizeof(struct rand_data));
+ /* initialize the entropy collector */
+ jent_read_entropy(&r->entropy_collector, rand, JENTBLOCKSIZE);
+ r->jent_enable = 1;
+ }
+ ret = jent_read_entropy(&r->entropy_collector, rand, JENTBLOCKSIZE);
+ if(JENTBLOCKSIZE == ret)
+ {
+ /* we do not need to worry about trickle threshold as we are called
+ * when we are low on entropy */
+ _mix_pool_bytes(r, rand, JENTBLOCKSIZE, NULL);
+ credit_entropy_bits(r, JENTBLOCKSIZE * 8);
+ }
+ memset(rand, 0, JENTBLOCKSIZE);
+}
+
/*
* Add device- or boot-specific data to the input and nonblocking
* pools to help initialize them to unique values.
@@ -862,6 +910,10 @@ static size_t account(struct entropy_sto
nbytes * 8, r->name);
/* Can we pull enough? */
+ /* XXX shall we limit this call to r->limit? */
+ if (r->entropy_count / 8 < min + reserved)
+ add_jent_randomness(r);
+
if (r->entropy_count / 8 < min + reserved) {
nbytes = 0;
} else {
^ permalink raw reply
* Re: [PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
From: Tim Chen @ 2013-05-23 0:32 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: linux-crypto, Julian Wollrath, Herbert Xu, David S. Miller
In-Reply-To: <20130521140941.15997.83258.stgit@localhost6.localdomain6>
On Tue, 2013-05-21 at 17:09 +0300, Jussi Kivilinna wrote:
> The _XFER stack element size was set too small, 8 bytes, when it needs to be
> 16 bytes. As _XFER is the last stack element used by these implementations,
> the 16 byte stores with 'movdqa' corrupt the stack where the value of register
> %r12 is temporarily stored. As these implementations align the stack pointer
> to 16 bytes, this corruption did not happen every time.
>
> Patch corrects this issue.
Thanks for catching and fixing the issue.
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Tim
^ permalink raw reply
* [PATCH] crypto: ux50: Cocci spatch "resource_size.spatch"
From: Thomas Meyer @ 2013-05-22 19:38 UTC (permalink / raw)
To: herbert, davem, linux-crypto, linux-kernel
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
---
diff -u -p a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1600,7 +1600,7 @@ static int ux500_cryp_remove(struct plat
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
- release_mem_region(res->start, res->end - res->start + 1);
+ release_mem_region(res->start, resource_size(res));
kfree(device_data);
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Stephan Mueller @ 2013-05-22 18:34 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFm=Quwx-Mi9s67jQe3HvJ55S3zb+3qsPxkYPvy4A+0Hrqw@mail.gmail.com>
On Wed, 22 May 2013 13:40:04 -0400
Sandy Harris <sandyinchina@gmail.com> wrote:
Hi Sandy,
> Stephan Mueller <smueller@chronox.de> wrote:
>
> > Ted is right that the non-deterministic behavior is caused by the OS
> > due to its complexity. ...
>
> >> > For VM's, it means we should definitely use
> >> > paravirtualization to get randomness from the host OS.
> >> ...
> >
> > That is already in place at least with KVM and Xen as QEMU can pass
> > through access to the host /dev/random to the guest. Yet, that
> > approach is dangerous IMHO because you have one central source of
> > entropy for the host and all guests. One guest can easily starve
> > all other guests and the host of entropy. I know that is the case
> > in user space as well.
>
> Yes, I have always thought that random(4) had a problem in that
> area; over-using /dev/urandom can affect /dev/random. I've never
> come up with a good way to fix it, though.
I think there is no way unless we either:
- use a seed source that is very fast, like hardware oscillators
- use a per-consumer seed source where the consumer can only hurt
himself when he overuses the resource
>
> > That is why I am offering an implementation that is able to
> > decentralize the entropy collection process. I think it would be
> > wrong to simply update /dev/random with another seed source of the
> > CPU jitter -- it could be done as one aspect to increase the
> > entropy in the system. I think users should slowly but surely
> > instantiate their own instance of an entropy collector.
>
> I'm not sure that's a good idea. Certainly for many apps just seeding
> a per-process PRNG well is enough, and a per-VM random device
> looks essential, though there are at least two problems possible
> because random(4) was designed before VMs were at all common
> so it is not clear it can cope with that environment. The host
> random device may be overwhelmed, and the guest entropy may
> be inadequate or mis-estimated because everything it relies on --
> devices, interrupts, ... -- is virtualised.
Right. That is why we need to open up other sources for entropy that
work also in a virtual environment.
The proposed solution generates entropy equally well in a virtual
environment as outlined in the documentation. I also performed testing
in virtual environments and obtained the same results as the tests on a
host system.
What could be done is:
- in the short term to wire up the CPU Jitter RNG to /dev/random as
another source for entropy in the host and the guest. This way,
the /dev/random implementation in the guest would get good entropy
without requiring host support.
- in the medium term, move consumers of entropy in user space and
kernel space (like SSL connections, VPN implementations,
OpenSSH, ....) to instantiate an independent copy of the jitter RNG
and thus easing the load on /dev/random. This can be implemented by
using the proposed connections to the different crypto libraries of
OpenSSL, libgcrypt, ..., and even the kernel crypto API. Every
consumer that has its own instance of the jitter RNG would not need to
call /dev/random any more
>
> I want to keep the current interface where a process can just
> read /dev/random or /dev/urandom as required. It is clean,
> simple and moderately hard for users to screw up. It may
I am not so sure about the last words. Using /dev/random correctly has
many pitfalls, IMHO:
- The OS must ensure that it is seeded during boot and that seed is
stored during shutdown. This is already a problem in many embedded
devices where this is done incorrectly.
- When you install full disk encryptions during the initial
installation, there is hardly any entropy in /dev/random (at least
when using a non-GUI installer), but you want to get entropy for a
very long living key.
- A simple read(fd) from /dev/random is not sufficient. You must take
care of EINTR. I have seen many uses of /dev/random where developers
even overlooked that simple problem.
- Currently /dev/random uses SSDs as seed source. You must manually
turn them off as seed source via /sys files.
> need some behind-the-scenes improvements to handle new
> loads, but I cannot see changing the interface itself.
I am not proposing any change to that interface. I am proposing a
complete independent offering of an entropy source that a caller could
use instead of /dev/random, if he wishes.
>
> > I would personally think that precisely for routers, the approach
> > fails, because there may be no high-resolution timer. At least
> > trying to execute my code on a raspberry pie resulted in a failure:
> > the initial jent_entropy_init() call returned with the indication
> > that there is no high-res timer.
>
> My maxwell(8) uses the hi-res timer by default but also has a
> compile-time option to use the lower-res timer if required. You
> still get entropy, just not as much.
>
> This affects more than just routers. Consider using Linux on
> a tablet PC or in a web server running in a VM. Neither needs
> the realtime library; in fact adding that may move them away
> from their optimisation goals.
>
> >> > What I'm against is relying only on solutions such as HAVEGE or
> >> > replacing /dev/random with something scheme that only relies on
> >> > CPU timing and ignores interrupt timing.
> >>
> >> My question is how to incorporate some of that into /dev/random.
> >> At one point, timing info was used along with other stuff. Some
> >> of that got deleted later, What is the current state? Should we
> >> add more?
> >
> > Again, I would like to suggest that we look beyond a central entropy
> > collector like /dev/random. I would like to suggest to consider
> > decentralizing the collection of entropy.
>
> I'm with Ted on this one.
When you want to consider the jitter RNG for /dev/random, it should be
used as a seed source similar to the add_*_randomness functions. I
could implement a suggestion if that is the wish. For example, such a
seed source could be triggered if the entropy estimator of the
input_pool falls below some threshold. The jitter RNG could be used to
top the entropy off to some level above another threshold.
But again, the long term goal is that there is no need of central
entropy collection device like /dev/random any more.
Ciao
Stephan
>
> --
> Who put a stop payment on my reality check?
--
| Cui bono? |
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Sandy Harris @ 2013-05-22 17:40 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <20130522082058.5592b2aa@tauon>
Stephan Mueller <smueller@chronox.de> wrote:
> Ted is right that the non-deterministic behavior is caused by the OS
> due to its complexity. ...
>> > For VM's, it means we should definitely use
>> > paravirtualization to get randomness from the host OS.
>> ...
>
> That is already in place at least with KVM and Xen as QEMU can pass
> through access to the host /dev/random to the guest. Yet, that approach
> is dangerous IMHO because you have one central source of entropy for
> the host and all guests. One guest can easily starve all other guests
> and the host of entropy. I know that is the case in user space as well.
Yes, I have always thought that random(4) had a problem in that
area; over-using /dev/urandom can affect /dev/random. I've never
come up with a good way to fix it, though.
> That is why I am offering an implementation that is able to
> decentralize the entropy collection process. I think it would be wrong
> to simply update /dev/random with another seed source of the CPU
> jitter -- it could be done as one aspect to increase the entropy in
> the system. I think users should slowly but surely instantiate their own
> instance of an entropy collector.
I'm not sure that's a good idea. Certainly for many apps just seeding
a per-process PRNG well is enough, and a per-VM random device
looks essential, though there are at least two problems possible
because random(4) was designed before VMs were at all common
so it is not clear it can cope with that environment. The host
random device may be overwhelmed, and the guest entropy may
be inadequate or mis-estimated because everything it relies on --
devices, interrupts, ... -- is virtualised.
I want to keep the current interface where a process can just
read /dev/random or /dev/urandom as required. It is clean,
simple and moderately hard for users to screw up. It may
need some behind-the-scenes improvements to handle new
loads, but I cannot see changing the interface itself.
> I would personally think that precisely for routers, the approach
> fails, because there may be no high-resolution timer. At least trying
> to execute my code on a raspberry pie resulted in a failure: the
> initial jent_entropy_init() call returned with the indication that
> there is no high-res timer.
My maxwell(8) uses the hi-res timer by default but also has a
compile-time option to use the lower-res timer if required. You
still get entropy, just not as much.
This affects more than just routers. Consider using Linux on
a tablet PC or in a web server running in a VM. Neither needs
the realtime library; in fact adding that may move them away
from their optimisation goals.
>> > What I'm against is relying only on solutions such as HAVEGE or
>> > replacing /dev/random with something scheme that only relies on CPU
>> > timing and ignores interrupt timing.
>>
>> My question is how to incorporate some of that into /dev/random.
>> At one point, timing info was used along with other stuff. Some
>> of that got deleted later, What is the current state? Should we
>> add more?
>
> Again, I would like to suggest that we look beyond a central entropy
> collector like /dev/random. I would like to suggest to consider
> decentralizing the collection of entropy.
I'm with Ted on this one.
--
Who put a stop payment on my reality check?
^ permalink raw reply
* Re: [PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
From: Julian Wollrath @ 2013-05-22 14:51 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-crypto, Tim Chen, Herbert Xu, David S. Miller
In-Reply-To: <20130521140941.15997.83258.stgit@localhost6.localdomain6>
Hi,
> The _XFER stack element size was set too small, 8 bytes, when it
> needs to be 16 bytes. As _XFER is the last stack element used by
> these implementations, the 16 byte stores with 'movdqa' corrupt the
> stack where the value of register %r12 is temporarily stored. As
> these implementations align the stack pointer to 16 bytes, this
> corruption did not happen every time.
>
> Patch corrects this issue.
>
> Reported-by: Julian Wollrath <jwollrath@web.de>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Tested-by: Julian Wollrath <jwollrath@web.de>
Thank you for fixing this issue.
Best regards,
Julian Wollrath
> ---
> arch/x86/crypto/sha256-avx-asm.S | 2 +-
> arch/x86/crypto/sha256-ssse3-asm.S | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/crypto/sha256-avx-asm.S
> b/arch/x86/crypto/sha256-avx-asm.S index 56610c4..642f156 100644
> --- a/arch/x86/crypto/sha256-avx-asm.S
> +++ b/arch/x86/crypto/sha256-avx-asm.S
> @@ -118,7 +118,7 @@ y2 = %r15d
>
> _INP_END_SIZE = 8
> _INP_SIZE = 8
> -_XFER_SIZE = 8
> +_XFER_SIZE = 16
> _XMM_SAVE_SIZE = 0
>
> _INP_END = 0
> diff --git a/arch/x86/crypto/sha256-ssse3-asm.S
> b/arch/x86/crypto/sha256-ssse3-asm.S index 98d3c39..f833b74 100644
> --- a/arch/x86/crypto/sha256-ssse3-asm.S
> +++ b/arch/x86/crypto/sha256-ssse3-asm.S
> @@ -111,7 +111,7 @@ y2 = %r15d
>
> _INP_END_SIZE = 8
> _INP_SIZE = 8
> -_XFER_SIZE = 8
> +_XFER_SIZE = 16
> _XMM_SAVE_SIZE = 0
>
> _INP_END = 0
>
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Stephan Mueller @ 2013-05-22 6:20 UTC (permalink / raw)
To: Sandy Harris; +Cc: Theodore Ts'o, LKML, linux-crypto
In-Reply-To: <CACXcFmnyDh7kBN3SCLGH3DcHH2gZO2_7weL_pch00g+3Jsjegg@mail.gmail.com>
On Tue, 21 May 2013 17:39:49 -0400
Sandy Harris <sandyinchina@gmail.com> wrote:
Hi Sandy,
> On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> > I continue to be suspicious about claims that userspace timing
> > measurements are measuring anything other than OS behaviour.
>
> Yes, but they do seem to contain some entropy. See links in the
> original post of this thread, the havege stuff and especially the
> McGuire et al paper.
Ted is right that the non-deterministic behavior is caused by the OS
due to its complexity. This complexity implies that you do not have a
clue what the fill levels of caches are, placement of data in RAM, etc.
I would expect that if you would have a tiny microkernel as your sole
software body on a CPU, there would be hardly any jitter. On the other
hand, the jitter is not mainly caused by interrupts and such, because
interrupts would cause a time delta that is by orders of magnitude
higher than most deltas (deltas vary around 20 to 40, interrupts cause
deltas in the mid thousands at least and ranging to more than 100,000).
>
> > But that
> > doesn't mean that they shouldn't exist. Personally, I believe you
> > should try to collect as much entropy as you can, from as many
> > places as you can.
>
> Yes.
That is the goal with the collection approach I offer. With the
repetition of the time delta measurements thousands of times to get one
64 bit random value, the goal is that you magnify and collect that tiny
bit of entropy.
My implementation is based on a sound mathematical base as I only use
XOR and concatenation of data. It has been reviewed by a mathematician
and other folks who worked on RNGs for a long time. Thus, once you
accept that the root cause typically delivers more than 1 bit of
entropy per measurement (the measurements I did showed more than 2 bits
of Shannon Entropy), then the collection process will result in a
random number that contains the claimed entropy.
>
> > For VM's, it means we should definitely use
> > paravirtualization to get randomness from the host OS.
>
> Yes, I have not worked out the details but it seems clear that
> something along those lines would be a fine idea.
That is already in place at least with KVM and Xen as QEMU can pass
through access to the host /dev/random to the guest. Yet, that approach
is dangerous IMHO because you have one central source of entropy for
the host and all guests. One guest can easily starve all other guests
and the host of entropy. I know that is the case in user space as well.
That is why I am offering an implementation that is able to
decentralize the entropy collection process. I think it would be wrong
to simply update /dev/random with another seed source of the CPU
jitter -- it could be done as one aspect to increase the entropy in
the system. I think users should slowly but surely instantiate their own
instance of an entropy collector.
>
> > For devices like Linux routers, what we desperately need is hardware
> > assist; [or] mix
> > in additional timing information either at kernel device driver
> > level, or from systems such as HAVEGE.
I would personally think that precisely for routers, the approach
fails, because there may be no high-resolution timer. At least trying
to execute my code on a raspberry pie resulted in a failure: the
initial jent_entropy_init() call returned with the indication that
there is no high-res timer.
> >
> > What I'm against is relying only on solutions such as HAVEGE or
> > replacing /dev/random with something scheme that only relies on CPU
> > timing and ignores interrupt timing.
>
> My question is how to incorporate some of that into /dev/random.
> At one point, timing info was used along with other stuff. Some
> of that got deleted later, What is the current state? Should we
> add more?
Again, I would like to suggest that we look beyond a central entropy
collector like /dev/random. I would like to suggest to consider
decentralizing the collection of entropy.
Ciao
Stephan
>
> --
> Who put a stop payment on my reality check?
--
| Cui bono? |
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Sandy Harris @ 2013-05-21 21:39 UTC (permalink / raw)
To: Theodore Ts'o, Sandy Harris, LKML, linux-crypto,
Stephan Mueller
In-Reply-To: <20130521190157.GD22559@thunk.org>
On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> I continue to be suspicious about claims that userspace timing
> measurements are measuring anything other than OS behaviour.
Yes, but they do seem to contain some entropy. See links in the
original post of this thread, the havege stuff and especially the
McGuire et al paper.
> But that
> doesn't mean that they shouldn't exist. Personally, I believe you
> should try to collect as much entropy as you can, from as many places
> as you can.
Yes.
> For VM's, it means we should definitely use
> paravirtualization to get randomness from the host OS.
Yes, I have not worked out the details but it seems clear that
something along those lines would be a fine idea.
> For devices like Linux routers, what we desperately need is hardware
> assist; [or] mix
> in additional timing information either at kernel device driver level,
> or from systems such as HAVEGE.
>
> What I'm against is relying only on solutions such as HAVEGE or
> replacing /dev/random with something scheme that only relies on CPU
> timing and ignores interrupt timing.
My question is how to incorporate some of that into /dev/random.
At one point, timing info was used along with other stuff. Some
of that got deleted later, What is the current state? Should we
add more?
--
Who put a stop payment on my reality check?
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Theodore Ts'o @ 2013-05-21 19:01 UTC (permalink / raw)
To: Sandy Harris; +Cc: LKML, linux-crypto
In-Reply-To: <CACXcFm=PCPs23Kd8B0+B7418fSaz=59Z4DRcj3-Wcd-i=Meang@mail.gmail.com>
I continue to be suspicious about claims that userspace timing
measurements are measuring anything other than OS behaviour. But that
doesn't mean that they shouldn't exist. Personally, I believe you
should try to collect as much entropy as you can, from as many places
as you can. For VM's, it means we should definitely use
paravirtualization to get randomness from the host OS. If you don't
trust the host OS, then what on earth are you doing trying to generate
a long-term public key pair on the VM in the first place? For that
matter, why are you willing to expose a high value private keypair on
the VM?
For devices like Linux routers, what we desperately need is hardware
assist; either a on-CPU hardware random number generator, or a
hardware RNG from a TPM module, or having an individualized secret key
generated at manufacturing time and burned onto the device. If you
don't trust that the Intel hardware RNG honest, then by all means mix
in additional timing information either at kernel device driver level,
or from systems such as HAVEGE.
What I'm against is relying only on solutions such as HAVEGE or
replacing /dev/random with something scheme that only relies on CPU
timing and ignores interrupt timing.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Stephan Mueller @ 2013-05-21 16:56 UTC (permalink / raw)
To: Sandy Harris; +Cc: linux-crypto, LKML
In-Reply-To: <CACXcFmmPjGBYhfbwfMdE2iTv2a9Q6HB1aT8JSnXA-8n2yO0zcA@mail.gmail.com>
On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris <sandyinchina@gmail.com> wrote:
Hi Sandy,
> I very much like the basic notion here. The existing random(4) driver
> may not get enough entropy in a VM or on a device like a Linux router
> and I think work such as yours or HAVEGE (
> http://www.irisa.fr/caps/projects/hipsor/) are important research. The
> paper by McGuire et al of "Analysis of inherent randomness of the
> Linux
> kernel" (http://lwn.net/images/conf/rtlws11/random-hardware.pdf)
> seems to show that this is a fine source of more entropy.
>
> On the other hand, I am not certain you are doing it in the right
> place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/)
> put it in a demon that just feeds /dev/random, probably also not the
> right place. haveged(8) ( http://www.issihosts.com/haveged/) also
> puts it in a demon process. It may, as you suggest, belong in the
> kernel instead, but I think there are arguments both ways.
Thanks for your insights. What I propose is that it shall NOT have any
fixed place at all.
The entropy collection shall be as close to the "consumer" as
possible. There shall be NO single one entropy collector, but one for
every consumer.
That is the reason, why the code I am offering has that many links to
different crypto libs or even a stand-alone shared lib compilation.
Also, the implementation for the kernel crypto API should be used in a
way where one "consumer" instantiates the raw RNG or even the DRNGs
independently from others. That means, in-kernel users of entropy like
IPSEC shall instantiate the the kernel crypto API code independently
of others.
>
> Could we keep random(4) mostly as is and rearrange your code to just
> give it more entropy? I think the large entropy pool in the existing
> driver is essential since we sometimes want to generate things like a
> 2 Kbit PGP key and it is not clear to me that your driver is entirely
> trustworthy under such stress.
We can easily do that -- the different links I provide to different
crypto libs can be extended by a patch to random(4) too. My goal is to
go away from a central source of entropy to a fully decentralized
source.
Ciao
Stephan
--
| Cui bono? |
^ permalink raw reply
* Re: [PATCH][RFC] CPU Jitter random number generator (resent)
From: Sandy Harris @ 2013-05-21 16:43 UTC (permalink / raw)
To: LKML; +Cc: linux-crypto
In-Reply-To: <20130521084455.5c651991@tauon>
I very much like the basic notion here. The existing random(4) driver
may not get enough entropy in a VM or on a device like a Linux router
and I think work such as yours or HAVEGE
(http://www.irisa.fr/caps/projects/hipsor/) are important research.
The paper by McGuire et al of "Analysis of inherent randomness of the
Linux kernel" (http://lwn.net/images/conf/rtlws11/random-hardware.pdf)
seems to show that this is a fine source of more entropy.
On the other hand, I am not certain you are doing it in the right
place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/)
put it in a demon that just feeds /dev/random, probably also not the
right place. haveged(8) (http://www.issihosts.com/haveged/) also puts
it in a demon process. It may, as you suggest, belong in the kernel
instead, but I think there are arguments both ways.
Could we keep random(4) mostly as is and rearrange your code to just
give it more entropy? I think the large entropy pool in the existing
driver is essential since we sometimes want to generate things like a
2 Kbit PGP key and it is not clear to me that your driver is entirely
trustworthy under such stress.
On Tue, May 21, 2013 at 2:44 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Hi,
>
> [1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2
>
> A new version of the CPU Jitter random number generator is released at
> http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy
> to read code. The readme in the main directory explains the different
> code files. A changelog can be found on the web site.
>
> In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first
> iteration received comments for the lack of tests, documentation and
> entropy assessment. All these concerns have been addressed. The
> documentation of the CPU Jitter random number generator
> (http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html and PDF at
> http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and
> pictures are better in PDF) offers a full analysis of:
>
> - the root cause of entropy
>
> - a design of the RNG
>
> - statistical tests and analyses
>
> - entropy assessment and explanation of the flow of entropy
>
> The document also explains the core concept to have a fully
> decentralized entropy collector for every caller in need of entropy.
>
> Also, this RNG is well suitable for virtualized environments.
> Measurements on OpenVZ and KVM environments have been conducted as
> documented. As the Linux kernel is starved of entropy in virtualized as
> well as server environments, new sources of entropy are vital.
>
> The appendix of the documentation contains example use cases by
> providing link code to the Linux kernel crypto API, libgcrypt and
> OpenSSL. Links to other cryptographic libraries should be straight
> forward to implement. These implementations follow the concept of
> decentralized entropy collection.
>
> The man page provided with the source code explains the use of the API
> of the CPU Jitter random number generator.
>
> The test cases used to compile the documentation are available at the
> web site as well.
>
> Note: for the kernel crypto API, please read the provided Kconfig file
> for the switches and which of them are recommended in regular
> operation. These switches must currently be set manually in the
> Makefile.
>
> Ciao
> Stephan
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Who put a stop payment on my reality check?
^ permalink raw reply
* [PATCH 2/2] crypto: sha256_ssse3 - add sha224 support
From: Jussi Kivilinna @ 2013-05-21 14:10 UTC (permalink / raw)
To: linux-crypto; +Cc: Tim Chen, Herbert Xu, David S. Miller
In-Reply-To: <20130521141044.16352.75962.stgit@localhost6.localdomain6>
Add sha224 implementation to sha256_ssse3 module.
This also fixes sha256_ssse3 module autoloading issue when 'sha224' is used
before 'sha256'. Previously in such case, just sha256_generic was loaded and
not sha256_ssse3 (since it did not provide sha224). Now if 'sha256' was used
after 'sha224' usage, sha256_ssse3 would remain unloaded.
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
---
arch/x86/crypto/sha256_ssse3_glue.c | 57 ++++++++++++++++++++++++++++++++---
1 file changed, 52 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/sha256_ssse3_glue.c b/arch/x86/crypto/sha256_ssse3_glue.c
index 597d4da..50226c4 100644
--- a/arch/x86/crypto/sha256_ssse3_glue.c
+++ b/arch/x86/crypto/sha256_ssse3_glue.c
@@ -187,7 +187,36 @@ static int sha256_ssse3_import(struct shash_desc *desc, const void *in)
return 0;
}
-static struct shash_alg alg = {
+static int sha224_ssse3_init(struct shash_desc *desc)
+{
+ struct sha256_state *sctx = shash_desc_ctx(desc);
+
+ sctx->state[0] = SHA224_H0;
+ sctx->state[1] = SHA224_H1;
+ sctx->state[2] = SHA224_H2;
+ sctx->state[3] = SHA224_H3;
+ sctx->state[4] = SHA224_H4;
+ sctx->state[5] = SHA224_H5;
+ sctx->state[6] = SHA224_H6;
+ sctx->state[7] = SHA224_H7;
+ sctx->count = 0;
+
+ return 0;
+}
+
+static int sha224_ssse3_final(struct shash_desc *desc, u8 *hash)
+{
+ u8 D[SHA256_DIGEST_SIZE];
+
+ sha256_ssse3_final(desc, D);
+
+ memcpy(hash, D, SHA224_DIGEST_SIZE);
+ memset(D, 0, SHA256_DIGEST_SIZE);
+
+ return 0;
+}
+
+static struct shash_alg algs[] = { {
.digestsize = SHA256_DIGEST_SIZE,
.init = sha256_ssse3_init,
.update = sha256_ssse3_update,
@@ -204,7 +233,24 @@ static struct shash_alg alg = {
.cra_blocksize = SHA256_BLOCK_SIZE,
.cra_module = THIS_MODULE,
}
-};
+}, {
+ .digestsize = SHA224_DIGEST_SIZE,
+ .init = sha224_ssse3_init,
+ .update = sha256_ssse3_update,
+ .final = sha224_ssse3_final,
+ .export = sha256_ssse3_export,
+ .import = sha256_ssse3_import,
+ .descsize = sizeof(struct sha256_state),
+ .statesize = sizeof(struct sha256_state),
+ .base = {
+ .cra_name = "sha224",
+ .cra_driver_name = "sha224-ssse3",
+ .cra_priority = 150,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA224_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+} };
#ifdef CONFIG_AS_AVX
static bool __init avx_usable(void)
@@ -227,7 +273,7 @@ static bool __init avx_usable(void)
static int __init sha256_ssse3_mod_init(void)
{
- /* test for SSE3 first */
+ /* test for SSSE3 first */
if (cpu_has_ssse3)
sha256_transform_asm = sha256_transform_ssse3;
@@ -254,7 +300,7 @@ static int __init sha256_ssse3_mod_init(void)
else
#endif
pr_info("Using SSSE3 optimized SHA-256 implementation\n");
- return crypto_register_shash(&alg);
+ return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
pr_info("Neither AVX nor SSSE3 is available/usable.\n");
@@ -263,7 +309,7 @@ static int __init sha256_ssse3_mod_init(void)
static void __exit sha256_ssse3_mod_fini(void)
{
- crypto_unregister_shash(&alg);
+ crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
module_init(sha256_ssse3_mod_init);
@@ -273,3 +319,4 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("SHA256 Secure Hash Algorithm, Supplemental SSE3 accelerated");
MODULE_ALIAS("sha256");
+MODULE_ALIAS("sha384");
^ permalink raw reply related
* [PATCH 1/2] crypto: sha512_ssse3 - add sha384 support
From: Jussi Kivilinna @ 2013-05-21 14:10 UTC (permalink / raw)
To: linux-crypto; +Cc: Tim Chen, Herbert Xu, David S. Miller
Add sha384 implementation to sha512_ssse3 module.
This also fixes sha512_ssse3 module autoloading issue when 'sha384' is used
before 'sha512'. Previously in such case, just sha512_generic was loaded and
not sha512_ssse3 (since it did not provide sha384). Now if 'sha512' was used
after 'sha384' usage, sha512_ssse3 would remain unloaded. For example, this
happens with tcrypt testing module since it tests 'sha384' before 'sha512'.
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
---
arch/x86/crypto/sha512_ssse3_glue.c | 58 ++++++++++++++++++++++++++++++++---
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/arch/x86/crypto/sha512_ssse3_glue.c b/arch/x86/crypto/sha512_ssse3_glue.c
index 6cbd8df..f30cd10 100644
--- a/arch/x86/crypto/sha512_ssse3_glue.c
+++ b/arch/x86/crypto/sha512_ssse3_glue.c
@@ -194,7 +194,37 @@ static int sha512_ssse3_import(struct shash_desc *desc, const void *in)
return 0;
}
-static struct shash_alg alg = {
+static int sha384_ssse3_init(struct shash_desc *desc)
+{
+ struct sha512_state *sctx = shash_desc_ctx(desc);
+
+ sctx->state[0] = SHA384_H0;
+ sctx->state[1] = SHA384_H1;
+ sctx->state[2] = SHA384_H2;
+ sctx->state[3] = SHA384_H3;
+ sctx->state[4] = SHA384_H4;
+ sctx->state[5] = SHA384_H5;
+ sctx->state[6] = SHA384_H6;
+ sctx->state[7] = SHA384_H7;
+
+ sctx->count[0] = sctx->count[1] = 0;
+
+ return 0;
+}
+
+static int sha384_ssse3_final(struct shash_desc *desc, u8 *hash)
+{
+ u8 D[SHA512_DIGEST_SIZE];
+
+ sha512_ssse3_final(desc, D);
+
+ memcpy(hash, D, SHA384_DIGEST_SIZE);
+ memset(D, 0, SHA512_DIGEST_SIZE);
+
+ return 0;
+}
+
+static struct shash_alg algs[] = { {
.digestsize = SHA512_DIGEST_SIZE,
.init = sha512_ssse3_init,
.update = sha512_ssse3_update,
@@ -211,7 +241,24 @@ static struct shash_alg alg = {
.cra_blocksize = SHA512_BLOCK_SIZE,
.cra_module = THIS_MODULE,
}
-};
+}, {
+ .digestsize = SHA384_DIGEST_SIZE,
+ .init = sha384_ssse3_init,
+ .update = sha512_ssse3_update,
+ .final = sha384_ssse3_final,
+ .export = sha512_ssse3_export,
+ .import = sha512_ssse3_import,
+ .descsize = sizeof(struct sha512_state),
+ .statesize = sizeof(struct sha512_state),
+ .base = {
+ .cra_name = "sha384",
+ .cra_driver_name = "sha384-ssse3",
+ .cra_priority = 150,
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA384_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+} };
#ifdef CONFIG_AS_AVX
static bool __init avx_usable(void)
@@ -234,7 +281,7 @@ static bool __init avx_usable(void)
static int __init sha512_ssse3_mod_init(void)
{
- /* test for SSE3 first */
+ /* test for SSSE3 first */
if (cpu_has_ssse3)
sha512_transform_asm = sha512_transform_ssse3;
@@ -261,7 +308,7 @@ static int __init sha512_ssse3_mod_init(void)
else
#endif
pr_info("Using SSSE3 optimized SHA-512 implementation\n");
- return crypto_register_shash(&alg);
+ return crypto_register_shashes(algs, ARRAY_SIZE(algs));
}
pr_info("Neither AVX nor SSSE3 is available/usable.\n");
@@ -270,7 +317,7 @@ static int __init sha512_ssse3_mod_init(void)
static void __exit sha512_ssse3_mod_fini(void)
{
- crypto_unregister_shash(&alg);
+ crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
}
module_init(sha512_ssse3_mod_init);
@@ -280,3 +327,4 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("SHA512 Secure Hash Algorithm, Supplemental SSE3 accelerated");
MODULE_ALIAS("sha512");
+MODULE_ALIAS("sha384");
^ permalink raw reply related
* [PATCH] crypto: sha512_generic - set cra_driver_name
From: Jussi Kivilinna @ 2013-05-21 14:10 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu, David S. Miller
'sha512_generic' should set driver name now that there is alternative sha512
provider (sha512_ssse3).
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
---
crypto/sha512_generic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c
index 4c58620..6ed124f 100644
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -251,6 +251,7 @@ static struct shash_alg sha512_algs[2] = { {
.descsize = sizeof(struct sha512_state),
.base = {
.cra_name = "sha512",
+ .cra_driver_name = "sha512-generic",
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SHA512_BLOCK_SIZE,
.cra_module = THIS_MODULE,
@@ -263,6 +264,7 @@ static struct shash_alg sha512_algs[2] = { {
.descsize = sizeof(struct sha512_state),
.base = {
.cra_name = "sha384",
+ .cra_driver_name = "sha384-generic",
.cra_flags = CRYPTO_ALG_TYPE_SHASH,
.cra_blocksize = SHA384_BLOCK_SIZE,
.cra_module = THIS_MODULE,
^ permalink raw reply related
* [PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
From: Jussi Kivilinna @ 2013-05-21 14:09 UTC (permalink / raw)
To: linux-crypto; +Cc: Julian Wollrath, Tim Chen, Herbert Xu, David S. Miller
The _XFER stack element size was set too small, 8 bytes, when it needs to be
16 bytes. As _XFER is the last stack element used by these implementations,
the 16 byte stores with 'movdqa' corrupt the stack where the value of register
%r12 is temporarily stored. As these implementations align the stack pointer
to 16 bytes, this corruption did not happen every time.
Patch corrects this issue.
Reported-by: Julian Wollrath <jwollrath@web.de>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
---
arch/x86/crypto/sha256-avx-asm.S | 2 +-
arch/x86/crypto/sha256-ssse3-asm.S | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/sha256-avx-asm.S b/arch/x86/crypto/sha256-avx-asm.S
index 56610c4..642f156 100644
--- a/arch/x86/crypto/sha256-avx-asm.S
+++ b/arch/x86/crypto/sha256-avx-asm.S
@@ -118,7 +118,7 @@ y2 = %r15d
_INP_END_SIZE = 8
_INP_SIZE = 8
-_XFER_SIZE = 8
+_XFER_SIZE = 16
_XMM_SAVE_SIZE = 0
_INP_END = 0
diff --git a/arch/x86/crypto/sha256-ssse3-asm.S b/arch/x86/crypto/sha256-ssse3-asm.S
index 98d3c39..f833b74 100644
--- a/arch/x86/crypto/sha256-ssse3-asm.S
+++ b/arch/x86/crypto/sha256-ssse3-asm.S
@@ -111,7 +111,7 @@ y2 = %r15d
_INP_END_SIZE = 8
_INP_SIZE = 8
-_XFER_SIZE = 8
+_XFER_SIZE = 16
_XMM_SAVE_SIZE = 0
_INP_END = 0
^ permalink raw reply related
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Herbert Xu @ 2013-05-21 13:46 UTC (permalink / raw)
To: Tim Chen
Cc: Geert Uytterhoeven, Xiong Zhou, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <1369076985.27102.319.camel@schen9-DESK>
On Mon, May 20, 2013 at 12:09:45PM -0700, Tim Chen wrote:
> On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
>
> >
> > Nope this is still broken. We need to move the actual crct10dif
> > code into crypto/. I'll fix up the patch in the tree.
> >
> > Also I'm going to get rid of crc_t10dif_update_lib function. If you
> > still want to maintain the ordering you should do so using the
> > *_init constructs.
> >
>
> Herbert,
>
> I used the following constructs in the pclmulqdq version of t10dif
> to get the module loaded.
>
> static const struct x86_cpu_id crct10dif_cpu_id[] = {
> X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
> {}
> };
> MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
>
> However, the default generic algorithm is used
> in the library function. The options CRC_T10DIF, CRYPTO_CRCT10DIF
> and CRYPTO_CRCT10DIF_PCLMUL are selected as modules (which
> is most likely usage scenario in distribution) on my
> test machine. The library module and generic crypto module was loaded
> before the pclmulqdq t10dif module during boot. How should
> things be changed to get this crypto module loaded earlier before the
> library? Should we add another init call level between fs and device
> init calls for loading the available crypto algorithms?
> The crc_t10dif_update_lib was originally used to side step this issue.
OK, the way it's meant to work is that the all versions generic
or otherwise do not call themselves by the name of the algorithm.
Instead every implementation links itself to the algorithm via
a module alias. That way the first user will cause modprobe
to load all available versions and then rank them by priority.
However, now that I've looked at it it appears that crc32c and
crct10dif have not done this properly. I'll fix that up.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox