On Wed, 8 Jun 2016, Stephan Mueller wrote:
Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau:
Hi Mat,
+ used = ctx->used;
+
+ /* convert iovecs of output buffers into scatterlists */
+ while (iov_iter_count(&msg->msg_iter)) {
+ /* make one iovec availa
From: Ben Dooks
The __raw IO functions are not endian safe, so use the readl_relaxed
and writel_relaxed versions of these.
Signed-off-by: Ben Dooks
---
CC: Matt Mackall
CC: Krzysztof Kozlowski
CC: linux-crypto@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-samsung-...@vger
From: Anatoly Pugachev
Date: Wed, 8 Jun 2016 20:30:40 +0300
> Can someone please tell, why do we get a bunch of the following
> messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220,
> T5140, and T5240 servers)
>
> Asking, because I see the following lines on kernel boot (removing
> f
On Wed, Jun 8, 2016 at 8:30 PM, Anatoly Pugachev wrote:
> Hello!
>
> Can someone please tell, why do we get a bunch of the following
> messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220,
> T5140, and T5240 servers)
>
> Asking, because I see the following lines on kernel boot (removin
Hello!
Can someone please tell, why do we get a bunch of the following
messages on niagara2 cpu hardware (SPARC Enterprise T5120, T5220,
T5140, and T5240 servers)
Asking, because I see the following lines on kernel boot (removing
first field boot time stamp in cut):
mator@nvg5120:~/linux-sparc-b
The hash buffer is really HASH_BLOCK_SIZE bytes, someone
must have thought that memmove takes n*u32 words by mistake.
Tests work as good/bad as before after this patch.
Cc: Joakim Bech
Reported-by: David Binderman
Signed-off-by: Linus Walleij
---
drivers/crypto/ux500/hash/hash_core.c | 4 ++--
On Wed, May 18, 2016 at 9:46 AM, Herbert Xu wrote:
> On Mon, May 16, 2016 at 07:13:12PM +0100, David Binderman wrote:
>> Hello there,
>>
>> 1.
>>
>> linux-4.6/drivers/crypto/ux500/hash/hash_core.c:784]: (warning) Division by
>> result of sizeof(). memmove() expects a size in bytes, did you intend
Am Donnerstag, 26. Mai 2016, 22:14:29 schrieb Theodore Ts'o:
Hi Theodore,
> On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:
> > Using the kernel crypto API one can relieve the CPU of the crypto work, if
> > a hardware or assembler implementation is available. This may be of
> > p
On Wed, Jun 08, 2016 at 10:54:51AM +0800, Herbert Xu wrote:
> On Thu, Jun 02, 2016 at 12:06:48PM +, Benedetto, Salvatore wrote:
> >
> > Off the top of my head, with ECDH when the user gets a EGAIN, he wants
> > to reset the secret key only, not the params.
>
> I don't see any performance benef
Hi Stephan,
> > int rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> > const void *value, size_t vlen)
> > {
> > struct rsa_key *key = context;
> > + const u8 *ptr = value;
> > + int ret;
> >
> > - key->n = mpi_read_raw_data(value, vlen);
> > + while (!*ptr && v
Am Mittwoch, 8. Juni 2016, 17:15:00 schrieb Herbert Xu:
Hi Herbert, Tadeusz,
> On Wed, Jun 08, 2016 at 11:07:42AM +0200, Stephan Mueller wrote:
> > No, it does not:
> >
> > #ifdef CONFIG_X86_64
>
> Well there is no fundamental reason why we can't do it on 32-bit.
> Even if we just did the count
On Wed, Jun 08, 2016 at 11:07:42AM +0200, Stephan Mueller wrote:
>
> No, it does not:
>
> #ifdef CONFIG_X86_64
Well there is no fundamental reason why we can't do it on 32-bit.
Even if we just did the counter increment in C this would still
beat ctr(aes-aesni) by many orders of magnitude.
So if
Am Mittwoch, 8. Juni 2016, 17:03:54 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Jun 08, 2016 at 10:58:37AM +0200, Stephan Mueller wrote:
> > Indeed, I used ctr(aes-aesni) instead of ctr-aes-aesni according to the
> > refcnt in /proc/crypto. The reason was that I used the sync skcipher API
> > which
On Wed, Jun 08, 2016 at 10:58:37AM +0200, Stephan Mueller wrote:
>
> Indeed, I used ctr(aes-aesni) instead of ctr-aes-aesni according to the
> refcnt
> in /proc/crypto. The reason was that I used the sync skcipher API which
> naturally excludes the ctr-aes-aesni.
>
> When changing it to really
Am Mittwoch, 8. Juni 2016, 16:00:55 schrieb Herbert Xu:
Hi Herbert,
> On Wed, Jun 08, 2016 at 09:56:42AM +0200, Stephan Mueller wrote:
> > The performance with ctr-aes-aesni on 64 bit is as follows -- I used my
> > LRNG implementation for testing for which I already have performance
> > measureme
On Mon, Jun 06, 2016 at 01:20:31PM +0200, Christophe Leroy wrote:
> This set of patches provides the implementation of AEAD for
> talitos SEC1.
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To
This patch implements an scomp backend for the lz4hc compression algorithm.
This way, lz4hc is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lz4hc.c | 92 +--
2 files changed, 83 insertions
This patch implements an scomp backend for the lz4 compression algorithm.
This way, lz4 is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lz4.c | 91 +--
2 files changed, 82 insertions(+),
This patch implements an scomp backend for the deflate compression
algorithm. This way, deflate is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/deflate.c | 111 +-
2 files changed, 102 in
This patch adds tests to the test manager for algorithms exposed through
the acomp api
Signed-off-by: Giovanni Cabiddu
---
crypto/testmgr.c | 158 +-
1 files changed, 145 insertions(+), 13 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/t
This patch implements an scomp backend for the 842 compression algorithm.
This way, 842 is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/842.c | 82 +--
crypto/Kconfig |1 +
2 files changed, 80 insertions(+),
Add a synchronous back-end (scomp) to acomp. This allows to easily expose
the already present compression algorithms in LKCF via acomp
Signed-off-by: Giovanni Cabiddu
---
crypto/Makefile |1 +
crypto/acompress.c | 49 +++-
crypto/scompress.c
This patch introduces acomp, an asynchronous compression api that uses
scatterlist buffers.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig | 10 ++
crypto/Makefile |2 +
crypto/acompress.c | 118
crypto/crypto_
The following patch set introduces acomp, a generic asynchronous
(de)compression api with support for SG lists.
We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
and struct crypto_acomp, together with number of helper functions to register
acomp type algorithms and alloc
This patch implements an scomp backend for the lzo compression algorithm.
This way, lzo is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lzo.c | 97 +++-
2 files changed, 83 insertions(+)
Am Mittwoch, 8. Juni 2016, 09:56:42 schrieb Stephan Mueller:
Hi Stephan,
> Am Mittwoch, 8. Juni 2016, 10:41:40 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Thu, Jun 02, 2016 at 02:06:55PM +0200, Stephan Mueller wrote:
> > > I am working on it. During the analysis, I saw, however, that the DRBG
On Wed, Jun 08, 2016 at 09:56:42AM +0200, Stephan Mueller wrote:
>
> The performance with ctr-aes-aesni on 64 bit is as follows -- I used my LRNG
> implementation for testing for which I already have performance measurements:
>
> - generating smaller lengths (I tested up to 128 bytes) of random n
Am Mittwoch, 8. Juni 2016, 10:41:40 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jun 02, 2016 at 02:06:55PM +0200, Stephan Mueller wrote:
> > I am working on it. During the analysis, I saw, however, that the DRBG
> > increments the counter before the encryption whereas the the CTR mode
> > increment
28 matches
Mail list logo
