Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef : > It really is an observation about overhead of context switches between > dm-crypt and > whatever/wherever you handle crypto - be it an off CPU hardware engine > or a bunch > of parallel kernel threads running on other cores. You

[PATCH v2] crypto: gcm - Fix IV buffer size in crypto_gcm_setkey

of the IV buffer to 16 bytes. Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers") Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- (Sorry for previous broken patch, hopefully I got it right this time.) I randomly noticed this while going over igcm.c for an

[RFC PATCH 1/6] crypto: skcipher - Add bulk request processing API

. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- crypto/Makefile| 1 + crypto/skcipher.c | 15 ++ crypto/skcipher_bulk.c | 312 + include/crypto/internal/skcipher.h | 32 include/

[RFC PATCH 4/6] crypto: simd - Add bulk request support

This patch adds proper support for the new bulk requests to the SIMD helpers. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- crypto/simd.c | 61 +++ 1 file changed, 61 insertions(+) diff --git a/crypto/simd.c b/crypto/

[RFC PATCH 3/6] crypto: cryptd - Add skcipher bulk request support

This patch adds proper support for the new bulk requests to cryptd. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- crypto/cryptd.c | 111 1 file changed, 111 insertions(+) diff --git a/crypto/cryptd.c b/crypto/cryptd.c

[RFC PATCH 6/6] dm-crypt: Add bulk crypto processing support

still sends only one sector in each request, since in such case the neighboring sectors are encrypted with different keys. This change causes a detectable read/write speedup (about 5-10%) on a ramdisk when AES-NI accelerated ciphers are used. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.

[RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support

This patch implements bulk request handling in the AES-NI crypto drivers. The major advantage of this is that with bulk requests, the kernel_fpu_* functions (which are usually quite slow) are now called only once for the whole request. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.

[RFC PATCH 2/6] crypto: skcipher - Add bulk request support to walk

significant exception being that skciphers which somehow tweak the IV (e.g. XTS) must check the new nextmsg flag before processing each chunk and re-tweak the IV if it is set. For other ciphers skcipher_walk automatically switches to the next IV at message boundaries. Signed-off-by: Ondrej Mosnacek

[RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt

ciphers and dm-crypt device mapped over a ramdisk. To-be-done: testing the bulk API in testmgr.c documentation update Ondrej Mosnacek (6): crypto: skcipher - Add bulk request processing API crypto: skcipher - Add bulk request support to walk crypto: cryptd - Add skcipher bulk request

[PATCH] crypto: gf128mul - define gf128mul_x_ble in gf128mul.h

-by: Ondrej Mosnacek <omosna...@gmail.com> --- crypto/gf128mul.c | 11 --- include/crypto/gf128mul.h | 15 +-- 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c index 04facc0..2eab1a1 100644 --- a/crypto/gf12

[PATCH v2] crypto: gf128mul - define gf128mul_x_* in gf128mul.h

aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64 and CRYPTO_AES_NI_INTEL disabled). Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> Cc: Eric Biggers <ebigg...@google.com> --- crypto/gf128mul.c | 33 +-- include/crypto/gf1

[PATCH v3] crypto: gf128mul - define gf128mul_x_* in gf128mul.h

to ~235 MiB/s (measured using 'cryptsetup benchmark -c aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64 and CRYPTO_AES_NI_INTEL disabled). Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> Cc: Eric Biggers <ebigg...@google.com> --- v2 -> v3: constant-time implementation

[PATCH v5 3/4] crypto: glue_helper - remove the le128_gf128mul_x_ble function

The le128_gf128mul_x_ble function in glue_helper.h is now obsolete and can be replaced with the gf128mul_x_ble function from gf128mul.h. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- arch/x86/crypto/glue_helper.c | 3 ++- arch/x86/include/asm/crypto/glue_helper.

[PATCH v5 0/4] gf128mul refactoring

o the header, not just gf128mul_x_ble Ondrej Mosnacek (4): crypto: gf128mul - define gf128mul_x_* in gf128mul.h crypto: gf128mul - switch gf128mul_x_ble to le128 crypto: glue_helper - remove the le128_gf128mul_x_ble function crypto: xts - drop gf128mul dependency arch/x86/crypto/cam

[PATCH v5 1/4] crypto: gf128mul - define gf128mul_x_* in gf128mul.h

to ~235 MiB/s (measured using 'cryptsetup benchmark -c aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64 and CRYPTO_AES_NI_INTEL disabled). Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> Cc: Eric Biggers <ebigg...@google.com> --- crypto/gf128mul.c

[PATCH v5 2/4] crypto: gf128mul - switch gf128mul_x_ble to le128

and updating all users accordingly. Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- arch/x86/crypto/camellia_glue.c | 4 ++-- arch/x86/crypto/serpent_sse2_glue.c | 4 ++-- arch/x86/crypto/twofish_glue_3way.c | 4 ++-- crypto/xts.c

[PATCH v4] crypto: gf128mul - define gf128mul_x_* in gf128mul.h

to ~235 MiB/s (measured using 'cryptsetup benchmark -c aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64 and CRYPTO_AES_NI_INTEL disabled). Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> Cc: Eric Biggers <ebigg...@google.com> --- v3 -> v4: a faster version of gf128mul

dm-crypt IV generation (summary)

Hi all, I was tasked to post a summary the whole dm-crypt IV generation problem and all the suggested solutions along with their drawbacks, so here it goes... PROBLEM STATEMENT: Currently, dm-crypt uses a fixed 512-byte sector size and handles en-/decrypting of a bio by submitting a separate

Re: dm-crypt IV generation (summary)

2017-04-07 8:12 GMT+02:00 Herbert Xu <herb...@gondor.apana.org.au>: > On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote: >> >> ISSUES: >> a) The 'keycount' parameter. >> In order to support multi-key modes from Loop-AE

[PATCH] crypto: skcipher - Fix skcipher_walk_aead_common

rface") Cc: <sta...@vger.kernel.org> Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> --- crypto/skcipher.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/crypto/skcipher.c b/crypto/skcipher.c index 4faa0fd53b0c..6c45ed536664 100644 --- a/crypto/skcipher.c +++ b/crypt

[PATCH] crypto: morus640 - Fix out-of-bounds access

) Reported-by: syzbot+1fafa9c4cf42df33f...@syzkaller.appspotmail.com Reported-by: syzbot+d82643ba80bf6937c...@syzkaller.appspotmail.com Signed-off-by: Ondrej Mosnacek --- crypto/morus640.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/crypto/morus640.c b/crypto/morus6

Re: [PATCH] crypto: x86/aegis - Fix CPUID checks

On Thu, Aug 2, 2018 at 11:17 AM Ondrej Mosnacek wrote: > It turns out I had misunderstood how the x86_match_cpu() function works. > It evaluates a logical OR of the matching conditions, not logical AND. > This caused the CPU feature checks to pass even if only SSE2 (but not

[PATCH v2] crypto: x86/aegis,morus - Fix and simplify CPUID checks

API on-demand module loading is sufficient. Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") Fixes: 6ecc9d9ff91f ("crypto: x86 - Add optimized MORUS implementations") Signed-off-by: Ondrej Mosnacek --- arch/x86/crypto/aegis128-aesni-glue.c | 12 ++

[PATCH] crypto: x86/aegis - Fix CPUID checks

suffice to match on the more important feature at the alias level and let the init routine do the full check. Signed-off-by: Ondrej Mosnacek --- Hi Herbert, this patch fixes the CPU checks of the AEGIS AES-NI/SSE2 implementations that have been introduced in 4.18. Once reviewed, it should go

[PATCH] crypto: vmx - Fix sleep-in-atomic bugs

uot;crypto: vmx - Adding support for XTS") Cc: sta...@vger.kernel.org Signed-off-by: Ondrej Mosnacek --- This patch should fix the issue, but I didn't test it. (I'll see if I can find some time tomorrow to try and recompile the kernel on a PPC machine... in the meantime please review :) drivers/

[PATCH] crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2

Signed-off-by: Ondrej Mosnacek --- arch/x86/crypto/aegis128-aesni-glue.c | 1 - arch/x86/crypto/aegis128l-aesni-glue.c | 1 - arch/x86/crypto/aegis256-aesni-glue.c | 1 - arch/x86/crypto/morus1280-sse2-glue.c | 1 - arch/x86/crypto/morus640-sse2-glue.c | 1 - 5 files changed, 5 deletion

Re: [PATCH 2/2] crypto: aegis/generic - fix for big endian systems

= d0; > - d[1] = d1; > - d[2] = d2; > - d[3] = d3; > + d[0] = cpu_to_le32(d0 ^ le32_to_cpu(k[0])); > + d[1] = cpu_to_le32(d1 ^ le32_to_cpu(k[1])); > + d[2] = cpu_to_le32(d2 ^ le32_to_cpu(k[2])); > + d[3] = cpu_to_le32(d3 ^ le32_to_cpu(k[3])); > } > > #endif /* _CRYPTO_AEGIS_H */ > -- > 2.19.0 > Thanks, -- Ondrej Mosnacek Associate Software Engineer, Security Technologies Red Hat, Inc.

Re: [PATCH 2/2] crypto: aegis/generic - fix for big endian systems

On Mon, Oct 1, 2018 at 10:01 AM Ard Biesheuvel wrote: > On 1 October 2018 at 10:00, Ondrej Mosnacek wrote: > > On Sun, Sep 30, 2018 at 1:14 PM Ard Biesheuvel > > wrote: > >> On 30 September 2018 at 10:58, Ard Biesheuvel > >> wrote: > >> > Us

Re: [PATCH 2/2] crypto: aegis/generic - fix for big endian systems

> > I suppose this > > > + d[0] = cpu_to_le32(d0) ^ k[0]; > > + d[1] = cpu_to_le32(d1) ^ k[1]; > > + d[2] = cpu_to_le32(d2) ^ k[2]; > > + d[3] = cpu_to_le32(d3) ^ k[3]; > > should work fine as well Yeah, that looks nicer, but I'm not sure if it is completely OK to do bitwise/arithmetic operations directly on the __[lb]e* types... Maybe yes, but the code I've seen that used them usually seemed to treat them as opaque types. > > > } > > > > #endif /* _CRYPTO_AEGIS_H */ > > -- > > 2.19.0 > > -- Ondrej Mosnacek Associate Software Engineer, Security Technologies Red Hat, Inc.

Re: [PATCH] crypto: lrw - fix rebase error after out of bounds fix

mputation") > Signed-off-by: Ard Biesheuvel Reviewed-by: Ondrej Mosnacek > --- > crypto/lrw.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/crypto/lrw.c b/crypto/lrw.c > index 6fcf0d431185..0430ccd08728 100644 > --- a/crypto/lrw

Re: [PATCH 1/2] crypto: morus/generic - fix for big endian systems

") > Cc: # v4.18+ > Signed-off-by: Ard Biesheuvel Reviewed-by: Ondrej Mosnacek > --- > crypto/morus1280.c | 7 ++- > crypto/morus640.c | 16 > 2 files changed, 6 insertions(+), 17 deletions(-) > > diff --git a/crypto/morus1280.c b/crypto/m

Re: [PATCH v2 2/2] crypto: aegis/generic - fix for big endian systems

1d e9 e6 f2 ed b5 8e 1c 5f dc 1c > > Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations") > Cc: # v4.18+ > Signed-off-by: Ard Biesheuvel LGTM now, thanks! Reviewed-by: Ondrej Mosnacek > --- > crypto/aegis.h | 20 +--- &g