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 c
From: Mahipal Challa
This contains changes for adding compression/decompression h/w offload
functionality for both DEFLATE and LZS.
Signed-off-by: Mahipal Challa
Signed-off-by: Vishnu Nair
Signed-off-by: Jan Glauber
---
drivers/crypto/cavium/zip/Makefile | 5 +-
drivers/crypto/cavium
decompression (RFC 2395 and ANSI X3.241-1994)
- ADLER32 and CRC32 checksums for ZLIB (RFC 1950) and GZIP (RFC 1952)
The ZIP engine is presented as a PCI device. It supports DMA and
scatter-gather.
Signed-off-by: Mahipal Challa
Signed-off-by: Vishnu Nair
Signed-off-by: Jan Glauber
---
drivers/crypto
From: Mahipal Challa
Add statistics for compression/decompression hardware offload
under debugfs.
Signed-off-by: Mahipal Challa
Signed-off-by: Vishnu Nair
Signed-off-by: Jan Glauber
---
drivers/crypto/cavium/zip/zip_deflate.c | 10 ++
drivers/crypto/cavium/zip/zip_inflate.c | 12
+0100, 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
> >
> [...]
> > --- a/drivers/crypto/Makefile
> > +++ b/drivers/crypto/Makefile
> > @@ -27,6 +
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 correc
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 room
Ouch.
Acked-by: Jan Glauber
On Mon, 2011-02-07 at 20:28 +1100, Herbert Xu wrote:
> Hi:
>
> This patch fixes an old but nasty bug in the sha-s390 code.
>
> commit 9d20b571f5bda7273656e1b86ef91eddc94adacc
> Author: Herbert Xu
> Date: Mon Feb 7 20:26:06 2011 +1100
>
Hi Herbert,
good idea. I ended up with using openssl to create a test vector for
that special case but a published test vector is of course better.
With your sha patch applied sha1_s390 survives the tcrypt test.
--Jan
On Thu, 2011-02-17 at 14:25 +1100, Herbert Xu wrote:
> Hi:
>
> I'm going to
On Fri, 2011-02-18 at 07:52 +1100, Herbert Xu wrote:
> On Thu, Feb 17, 2011 at 04:11:02PM +0100, Jan Glauber wrote:
> > Hi Herbert,
> >
> > good idea. I ended up with using openssl to create a test vector for
> > that special case but a published test vector is of c
> Subject: [PATCH] crypto: extend crypto facility check
>
> From: Jan Glauber
>
> 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
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
> >
> > The specification which crypto facility is required for an a
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
> >
> > XTS mode is only defined for 256 and 512 bit key lengths. s390 only
> > implements these two modes and running
Hi Herbert,
this is the fallback code for XTS. It should fit on top of the s390 series.
thanks,
Jan
-
From: Jan Glauber
The z196 XTS acceleration only supports the two official XTS
modes (256 and 512 bit keys). Since the software XTS implementation
allows all three AES key lengths to be
On Tue, 2011-04-26 at 16:34 +1000, Herbert Xu wrote:
> On Tue, Apr 19, 2011 at 09:29:17PM +0200, j...@linux.vnet.ibm.com wrote:
> >
> > @@ -664,11 +784,6 @@ static int __init aes_s390_init(void)
> > if (ret)
> > goto cbc_aes_err;
> >
> > - /* skip XTS if MSA-4 is not available *
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
> > > su
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
---
arch/s390/crypto/sha256_s390.c | 66
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 tell
lg() with
> list_add(). Therefore perform cleanup to remove all unneeded initializations
> of this field in 'arch/s390/crypto/'
>
> Cc: Jan Glauber
> Cc: Gerald Schaefer
> Cc: linux-s...@vger.kernel.org
> Signed-off-by: Jussi Kivilinna
Signed-off-by: Jan Glauber
--
To u
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 m
t;
> diff --git a/arch/s390/crypto/sha1_s390.c b/arch/s390/crypto/sha1_s390.c
> index af4460e..8ebd3cd 100644
> --- a/arch/s390/crypto/sha1_s390.c
> +++ b/arch/s390/crypto/sha1_s390.c
> @@ -12,7 +12,7 @@
> * Author(s): Thomas Spatzier
> * Jan Glauber ([E
There are currently several SHA implementations that all define their own
initialization vectors and size values. Since this values are idential
move them to a header file under include/crypto.
The Patch should apply to cryptodev-2.6.
Signed-off-by: Jan Glauber <[EMAIL PROTECTED]>
---
arc
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/K
l pointer call. But maybe I'm just missing another patch...
thanks, Jan
> diff --git a/arch/s390/crypto/aes_s390.c b/arch/s390/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 V
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
===
--- cryptod
Hi Herbert,
commit 788fefa33b0b50581585925c53c230a36af35d0e in cryptodev breaks hmac
on s390 du to the usage of sg_chain():
static inline void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
struct scatterlist *sgl)
{
#ifndef ARCH_HAS_SG_CHAIN
BUG();
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.
Signed-off
[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 instru
On Fri, 2008-07-11 at 20:29 +0800, Herbert Xu wrote:
> On Thu, Jul 10, 2008 at 03:00:43PM +0000, Jan Glauber wrote:
> >
> > here is a small patch for the s390 crypto detection.
> >
> > [PATCH] respect STFL bit for s390 crypto
> >
> > From: <[EMAIL P
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
>
On Tue, 2009-02-03 at 12:48 +1100, Herbert Xu wrote:
> On Mon, Feb 02, 2009 at 06:01:07PM +0000, 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
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 Not
On Wed, 2009-02-25 at 11:51 +0800, Herbert Xu wrote:
> Jan Glauber wrote:
> >
> > That only happens if the aes_generic module isn't loaded. If
> > aes_generic is already present the aes_s390 loads without problems.
> >
> > Any idea how to solve this? Is
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 +0000, Jan Glau
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 missin
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
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
---
arch/s390/crypto
small delay between the reading attempts.
Signed-off-by: Jan Glauber
Reviewed-by: Robert Richter
Cc: stable # 4.14
---
drivers/crypto/cavium/zip/common.h | 22 ++
drivers/crypto/cavium/zip/zip_deflate.c | 4 ++--
drivers/crypto/cavium/zip/zip_inflate.c | 4 ++--
3 files
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
Reviewed-by: Robert Richter
Cc: stable # 4.14
---
drivers/crypto/cavium/zip/zip_crypto.c | 22 ++
1 file changed, 14
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
small delay between the reading attempts.
Signed-off-by: Jan Glauber
Reviewed-by: Robert Richter
Cc: stable # 4.14
---
drivers/crypto/cavium/zip/common.h | 21 +
drivers/crypto/cavium/zip/zip_deflate.c | 4 ++--
drivers/crypto/cavium/zip/zip_inflate.c | 4 ++--
3 files
Avoid two potential divisions by zero when calculating average
values for the zip statistics.
Signed-off-by: Jan Glauber
Reviewed-by: Robert Richter
---
drivers/crypto/cavium/zip/zip_main.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/cavium/zip
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
Reviewed-by: Robert Richter
---
drivers/crypto/cavium/zip/zip_main.c | 13 +
drivers/crypto/cavium/zip
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
occur but everything will continue to work, so just
ignore it.
Signed-off-by: Jan Glauber
Reviewed-by: Robert Richter
---
drivers/crypto/cavium/zip/zip_device.c | 4 ++--
drivers/crypto/cavium/zip/zip_main.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto
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
Reviewed-by: Robert Richter
Cc: stable # 4.14
---
drivers/crypto/cavium/zip/zip_crypto.c | 22 ++
1 file changed, 14
for test_comp().
Signed-off-by: Mahipal Challa
Signed-off-by: Balakrishna Bhamidipati
[jglau...@cavium.com: removed unrelated printk changes, rewrote commit msg,
fixed whitespace and unneeded initialization]
Signed-off-by: Jan Glauber
---
crypto/testmgr.c |
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;
> > }
> >
> &
the only algorithm 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: t
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_m
e 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
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 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
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
Hi Colin,
I've already posted a similar patch:
https://patchwork.kernel.org/patch/10482283/
--Jan
On Sat, Jun 30, 2018 at 12:30:49PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The functions zip_ctx_exit, zip_compress, zip_decompress and zip_ctx_init
> are local to the source and do no
> Cc: "David S. Miller"
> Cc: Robert Richter
> Cc: Jan Glauber
> Cc: linux-crypto@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/crypto/cavium/zip/zip_main.c | 52 ++--
> 1 file changed, 11 insertions(+), 41 deletions(-)
Reviewed-by: Jan Glauber
thanks,
Jan
the
> cra_driver_name of the cavium/zip algorithms.
The patch is fine, basically the same as:
https://marc.info/?l=linux-crypto-vger&m=152968599829763&w=2
Shouldn't we also rename deflate to deflate generic?
--Jan
> Fixes: 640035a2dc55 ("crypto: zip - Add ThunderX ZIP driver core&
2006-12-01 13:06:50.0
+0100
@@ -0,0 +1,206 @@
+/*
+ * Copyright 2006 IBM Corporation
+ * Author(s): Jan Glauber <[EMAIL PROTECTED]>
+ * Driver for the s390 pseudo random number generator
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
.c
linux-2.5_prng/arch/s390/crypto/prng.c
--- linux-2.5/arch/s390/crypto/prng.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.5_prng/arch/s390/crypto/prng.c 2006-12-01 16:14:22.0
+0100
@@ -0,0 +1,203 @@
+/*
+ * Copyright 2006 IBM Corporation
+ * Author(s): Jan Glauber <[EMAIL PROTECTED]
On Mon, 2006-12-04 at 11:15 -0500, [EMAIL PROTECTED] wrote:
> On Fri, 01 Dec 2006 14:19:15 +0100, Jan Glauber said:
> > New s390 machines have hardware support for the generation of pseudo-random
> > numbers. This patch implements a simple char driver that exports this
> >
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
On Thu, 2006-12-07 at 19:43 +0100, Arnd Bergmann wrote:
> On Thursday 07 December 2006 16:19, Jan Glauber wrote:
> > Hm, why is /dev/urandom implemented in the kernel?
> >
> > It could be done completely in user-space (like libica already does)
> > but I think having
On Tue, 2006-12-05 at 14:07 +0100, Jan Glauber wrote:
> Yes, if an attacker knows the initial clock value a brute-force attack
> would be feasible to predict the output. But I don't know if the
> hardware completely relies on the clock values or if there is any
> internal s
On Thu, 2007-02-08 at 15:26 -0800, David Miller wrote:
> There was a minor merge conflict to resolve, because the
> S390 guys removed a bunch of their crypto options from
> crypto/Kconfig in a seperate changeset. But I'm pretty
> sure I resolved that correctly.
I'll check when the git server wor
On Sat, 2007-03-17 at 21:28 +0100, Sebastian Siewior wrote:
> * Herbert Xu | 2007-03-17 15:12:17 [+1100]:
>
> >What exactly is the aes-special algorithm and where can I find a copy?
> The only difference between -special and -generic is the limited key
> size. It was just an example.
>
> >Yes key
67 matches
Mail list logo
