Hi Eric,
sorry for my late response.
On Fri, Jun 22, 2018 at 08:12:26PM -0700, Eric Biggers wrote:
> Hi Jan,
>
> On Fri, Jun 22, 2018 at 04:37:20PM +0200, Jan Glauber wrote:
> > While commit 336073840a87 ("crypto: testmgr - Allow different compression
> > results
On Fri, Jun 22, 2018 at 07:50:02PM -0700, Eric Biggers wrote:
> Hi Jan,
>
> On Fri, Jun 22, 2018 at 04:37:21PM +0200, Jan Glauber wrote:
> > The test vectors were generated using the ThunderX ZIP coprocessor.
> >
> > Signed-off-by: Jan Glauber
> &g
d
the same bytes the test would still pass.
Improve the compression test by using the generic variant (if available)
to decompress the compressed test vector from the non-generic
algorithm.
Suggested-by: Herbert Xu
Signed-off-by: Jan Glauber
---
crypto/testmgr.c | 23 ++-
1
The test vectors were generated using the ThunderX ZIP coprocessor.
Signed-off-by: Jan Glauber
---
crypto/testmgr.c | 9 ++
crypto/testmgr.h | 77
2 files changed, 86 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index
that could use the mixed test.
Jan Glauber (5):
crypto: deflate - Rename to generic
crypto: thunderx_zip - Add driver names and module aliases
crypto: testmgr - Improve compression/decompression test
crypto: testmgr - Add test vectors for LZS compression
crypto: thunderx_zip - Make functions
Add missing cra_driver_name's and module aliases for deflate and lzs.
Signed-off-by: Jan Glauber
---
drivers/crypto/cavium/zip/zip_main.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/cavium/zip/zip_main.c
b/drivers/crypto/cavium/zip/zip_main.c
Make functions static where possible, found by sparse.
Signed-off-by: Jan Glauber
---
drivers/crypto/cavium/zip/zip_crypto.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/cavium/zip/zip_crypto.c
b/drivers/crypto/cavium/zip/zip_crypto.c
Rename deflate -> deflate_generic and add the default priority of 100.
Signed-off-by: Jan Glauber
---
crypto/Makefile | 2 +-
crypto/{deflate.c => deflate_generic.c} | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
rename crypto/{deflate.c => deflate_
On Thu, Apr 19, 2018 at 11:42:11AM +0800, Herbert Xu wrote:
> On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote:
> >
> > @@ -1362,7 +1373,17 @@ static int test_comp(struct crypto_comp *tfm,
> > goto out;
> > }
> >
> &
test. Do something
similar for test_comp().
Signed-off-by: Mahipal Challa <mcha...@cavium.com>
Signed-off-by: Balakrishna Bhamidipati <bbhamidip...@cavium.com>
[jglau...@cavium.com: removed unrelated printk changes, rewrote commit msg,
fixed whitespace and unneeded initialization]
Signe
forever for the completion byte to contain a non-zero value.
Allocating the result struct from 1:1 mapped memory resolves this
bug.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
Cc: stable <sta...@vger.kernel.org> # 4.14
---
dri
Some bug fixes for this driver after it stopped working with virtual mapped
stacks. I think the first two patches qualify for stable.
Jan Glauber (5):
crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK
crypto: thunderx_zip: Limit result reading attempts
crypto: thunderx_zip: Prevent
will occur but everything will continue to work, so just
ignore it.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
---
drivers/crypto/cavium/zip/zip_device.c | 4 ++--
drivers/crypto/cavium/zip/zip_main.c | 2 +-
2 files changed, 3 inse
The pending request counter was read from the wrong register. While
at it, there is no need to use an atomic for it as it is only read
localy in a loop.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
---
drivers/crypto/cavium/zi
Avoid two potential divisions by zero when calculating average
values for the zip statistics.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
---
drivers/crypto/cavium/zip/zip_main.c | 9 +
1 file changed, 5 insertions(+),
and a small delay between the reading attempts.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
Cc: stable <sta...@vger.kernel.org> # 4.14
---
drivers/crypto/cavium/zip/common.h | 21 +
drivers/crypto/cavium/zip/
On Wed, Mar 28, 2018 at 03:05:56PM +0200, Jan Glauber wrote:
> Enabling virtual mapped kernel stacks breaks the thunderx_zip
> driver. On compression or decompression the executing CPU hangs
> in an endless loop. The reason for this is the usage of __pa
> by the driver which does no
forever for the completion byte to contain a non-zero value.
Allocating the result struct from 1:1 mapped memory resolves this
bug.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
Cc: stable <sta...@vger.kernel.org> # 4.14
---
dri
and a small delay between the reading attempts.
Signed-off-by: Jan Glauber <jglau...@cavium.com>
Reviewed-by: Robert Richter <rrich...@cavium.com>
Cc: stable <sta...@vger.kernel.org> # 4.14
---
drivers/crypto/cavium/zip/common.h | 22 ++
drivers/crypto/cavium/zip/
On Sat, Jul 22, 2017 at 02:16:41PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 21, 2017 at 04:55:12PM +0200, Oliver Mangold wrote:
> > On 21.07.2017 16:47, Theodore Ts'o wrote:
> > > On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote:
> > > > Better, but obviously there is still much
On Fri, Jul 21, 2017 at 09:12:01AM +0200, Oliver Mangold wrote:
> Hi,
>
> I was wondering why reading from /dev/urandom is much slower on
> Ryzen than on Intel, and did some analysis. It turns out that the
> RDRAND instruction is at fault, which takes much longer on AMD.
>
> if I read this
, Corentin Labbe wrote:
> Hello
>
> I have some comment below
>
> On Mon, Dec 12, 2016 at 04:04:37PM +0100, Jan Glauber wrote:
> > From: Mahipal Challa <mahipal.cha...@cavium.com>
> >
> [...]
> > --- a/drivers/crypto/Makefile
> > +++ b/d
Vishnu Nair <vishnu.n...@cavium.com>
Signed-off-by: Jan Glauber <jglau...@cavium.com>
---
drivers/crypto/Kconfig |7 +
drivers/crypto/Makefile|1 +
drivers/crypto/cavium/Makefile |4 +
drivers/crypto/cavium/zip/Makefile |8 +
d
From: Mahipal Challa <mahipal.cha...@cavium.com>
This contains changes for adding compression/decompression h/w offload
functionality for both DEFLATE and LZS.
Signed-off-by: Mahipal Challa <mahipal.cha...@cavium.com>
Signed-off-by: Vishnu Nair <vishnu.n...@cavium.com>
Signed-o
From: Mahipal Challa <mahipal.cha...@cavium.com>
Add statistics for compression/decompression hardware offload
under debugfs.
Signed-off-by: Mahipal Challa <mahipal.cha...@cavium.com>
Signed-off-by: Vishnu Nair <vishnu.n...@cavium.com>
Signed-off-by: Jan Glauber &l
Hi Herbert,
this series adds support for hardware accelerated compression & decompression
as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally
for some time and would like to get feedback on the RFC to see if this goes
into the right direction and to see if there are any
On Thu, Oct 31, 2013 at 11:25:47AM +0800, Herbert Xu wrote:
Hi:
Hi Herbert,
just seen this as my old email address is dead... Your patch looks
fine as it keeps the iv and the key together as required by the instruction.
However, I'm curious how this could be racy with threads. The encryption
(). Therefore perform cleanup to remove all unneeded initializations
of this field in 'arch/s390/crypto/'
Cc: Jan Glauber j...@de.ibm.com
Cc: Gerald Schaefer gerald.schae...@de.ibm.com
Cc: linux-s...@vger.kernel.org
Signed-off-by: Jussi Kivilinna jussi.kivili...@mbnet.fi
Signed-off-by: Jan
Hi Herbert,
I've noticed that the powerpc folks were able to sneak counters for
their hardware crypto implementation into upstream [1].
Simple counters for the number of processed bytes per algorithm is
something which I wanted to have for some time now. The reason is that
its not obvious to
On recent s390 machines hardware acceleration is available for SHA-256.
SHA-224 is based on SHA-256 so it can also be accelerated by hardware.
Do this by adding the proper algorithm description and initialization.
Signed-off-by: Jan Glauber j...@linux.vnet.ibm.com
---
arch/s390/crypto
On Wed, 2011-05-04 at 15:10 +1000, Herbert Xu wrote:
On Wed, Apr 27, 2011 at 08:40:04PM +1000, Herbert Xu wrote:
On Wed, Apr 27, 2011 at 12:37:20PM +0200, Jan Glauber wrote:
This hunk is a left-over from development in the XTS patch and
superfluous so it should be removed. Should I
Hi Herbert,
this is the fallback code for XTS. It should fit on top of the s390 series.
thanks,
Jan
-
From: Jan Glauber j...@linux.vnet.ibm.com
The z196 XTS acceleration only supports the two official XTS
modes (256 and 512 bit keys). Since the software XTS implementation
allows all three
On Wed, 2011-04-20 at 08:33 +0800, Herbert Xu wrote:
On Tue, Apr 19, 2011 at 09:29:20PM +0200, j...@linux.vnet.ibm.com wrote:
From: Jan Glauber j...@linux.vnet.ibm.com
XTS mode is only defined for 256 and 512 bit key lengths. s390 only
implements these two modes and running the test
Subject: [PATCH] crypto: extend crypto facility check
From: Jan Glauber j...@linux.vnet.ibm.com
The specification which crypto facility is required for an algorithm
is added
as a parameter to the availability check which is done before an
algorithm is
registered. With this change
Sorry, hit the undo once too often. Just ignore.
On Tue, 2011-04-19 at 13:23 +0200, Jan Glauber wrote:
Subject: [PATCH] crypto: extend crypto facility check
From: Jan Glauber j...@linux.vnet.ibm.com
The specification which crypto facility is required for an algorithm
is added
des_s390 implements support for 3DES with a 128 bit key. This mode is probably
not used anywhere, less secure than 3DES with a 192 bit key and not
implemented in the generic des version. Removing this mode seems to be low risk
and will ease maintenance of the code.
Signed-off-by: Jan Glauber j
Get rid of the des_s390 specific key check module and use the generic DES
weak key check instead. Also use the generic DES header and remove the
weak key check in 3DES mode, as RFC2451 mentions that the DES weak keys
are not relevant for 3DES.
Signed-off-by: Jan Glauber j...@linux.vnet.ibm.com
Hi,
Jan 14 14:47:38 h42lp52 kernel: alg: hash: Test 1 failed for vmac(aes-s390)
Jan 14 14:47:38 h42lp52 kernel: : e7 79 33 b7 fd 8a d7 cb
Looking at the digest from the failing test vector:
.digest = \xcb\xd7\x8a\xfd\xb7\x33\x79\xe7,
the output looks somehow familiar... Maybe a missing
Hi Herbert,
your patch solves the hanging modprobe (tested on top of cryptodev-2.6).
Both modules (aes_generic and aes_s390) are loaded after the modprobe
aes_s390.
Thanks a lot, Jan
On Thu, 2009-02-26 at 14:06 +0800, Herbert Xu wrote:
On Wed, Feb 25, 2009 at 05:33:50PM +, Jan Glauber
Hi Herbert,
commit 73d3864a4823abda19ebc4387b6ddcbf416e3a77 leads to a
hanging modprobe aes_s390 process. If the process is
interrupted the following oops occurs:
[ cut here ]
Badness at crypto/algapi.c:293
Modules linked in: aes_generic aes_s390(+) binfmt_misc
CPU: 0
On Tue, 2009-02-03 at 12:48 +1100, Herbert Xu wrote:
On Mon, Feb 02, 2009 at 06:01:07PM +, Jan Glauber wrote:
The patch is not yet in cryptodev, so I applied it on top of cryptodev.
Compiling it gives me the following error:
CC [M] arch/s390/crypto/sha256_s390.o
arch/s390
On Mon, 2009-02-02 at 13:20 +0100, Martin Schwidefsky wrote:
On Wed, 2009-01-28 at 14:56 +1100, Herbert Xu wrote:
On Mon, Jan 19, 2009 at 09:55:17AM +1100, Herbert Xu wrote:
Could you let me if this patch breaks s390?
commit 0fe7dddf02811152d7e58747bfe419ec0f43ea4e
Author:
[PATCH] respect STFL bit for s390 crypto
From: [EMAIL PROTECTED]
Bevore issuing any s390 crypto operation check whether the
CPACF facility is enabled in the facility list. That way a
virtualization layer can prevent usage of the CPACF facility
regardless of the availability of the crypto
Hi Herbert,
here is a small patch for the s390 crypto detection.
[PATCH] respect STFL bit for s390 crypto
From: [EMAIL PROTECTED]
For all s390 in-kernel crypto algorithms we check at module
load time whether the CPACF facility bit is on. If the facility
is not enabled we bail out.
Add test vectors to tcrypt for AES in CBC mode for key sizes 192 and 256.
The test vectors are copied from NIST SP800-38A.
Signed-off-by: Jan Glauber [EMAIL PROTECTED]
Index: cryptodev-2.6/crypto/tcrypt.h
===
--- cryptodev-2.6.orig
The HIFN driver is currently selectable on s390 but wont compile.
Since it looks like HIFN needs PCI make the Kconfig dependent on PCI,
which is not available on s390.
-jang
Signed-off-by: Jan Glauber [EMAIL PROTECTED]
Index: cryptodev-2.6/drivers/crypto/Kconfig
/crypto/aes_s390.c
index 812511b..393a450 100644
--- a/arch/s390/crypto/aes_s390.c
+++ b/arch/s390/crypto/aes_s390.c
@@ -6,6 +6,7 @@
* s390 Version:
* Copyright IBM Corp. 2005,2007
* Author(s): Jan Glauber ([EMAIL PROTECTED])
+ * Sebastian Siewior ([EMAIL PROTECTED] SW
On Thu, 2006-12-07 at 16:06 +0100, Arnd Bergmann wrote:
On Friday 01 December 2006 14:19, Jan Glauber wrote:
I've chosen the char driver since it allows the user to decide which
pseudo-random
numbers he wants to use. That means there is a new interface for the s390
PRNG, called /dev
48 matches
Mail list logo
