[PATCH 1/4] crypto: gf128mul - fix some comments

Fix incorrect references to GF(128) instead of GF(2^128), as these are two entirely different fields, and fix a few other incorrect comments. Cc: Alex Cope <alexc...@google.com> Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/gf128mul.c | 13 +++-- in

[PATCH 4/4] crypto: gf128mul - constify 4k and 64k multiplication tables

Constify the multiplication tables passed to the 4k and 64k multiplication functions, as they are not modified by these functions. Cc: Alex Cope <alexc...@google.com> Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/gf128mul.c | 6 +++--- include/crypto/gf

[PATCH 2/4] crypto: gf128mul - remove xx() macro

The xx() macro serves no purpose and can be removed. Cc: Alex Cope <alexc...@google.com> Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/gf128mul.c | 18 -- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/crypto/gf128mul.c b/crypto/gf12

[PATCH 0/4] crypto: gf128mul cleanups

This patchset makes a few cleanups to the generic GF(2^128) multiplication code to make it slightly easier to understand and modify. No functional changes are intended. Eric Biggers (4): crypto: gf128mul - fix some comments crypto: gf128mul - remove xx() macro crypto: gf128mul - rename

[PATCH 3/4] crypto: gf128mul - rename the byte overflow tables

tiplication. Therefore, rename the tables to "le" and "be" and update the comment to explain this. Cc: Alex Cope <alexc...@google.com> Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/gf128mul.c | 49 - 1 file c

Re: [PATCH] lz4: fix performance regressions

Hi Sven, On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote: > /*- > * Reading and writing into memory > **/ > +typedef union { > + U16 u16; > + U32 u32; > + size_t uArch; > +} __packed unalign; >

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 12:02:11PM +0100, Sven Schmidt wrote: > > > > [Also, for some reason linux-crypto is apparently still not receiving patch > > 1/5 > > in the series. It's missing from the linux-crypto archive at > > http://www.spinics.net/lists/linux-crypto/, so it's not just me.] > > >

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 12:05:40PM +0100, Sven Schmidt wrote: > > Because of how LZ4_ARCH64 is defined, it needs to be '#if LZ4_ARCH64'. > > > > But I also think the way upstream LZ4 does 64-bit detection could have just > > been > > left as-is; it has a function which gets inlined: > > > >

Re: [PATCH v7 0/5] Update LZ4 compressor module

On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote: > > Today, I did zram-lz4 performance test with fio in current mmotm and > found it makes regression about 20%. > This may or may not be the cause of the specific regression you're observing, but I just noticed that the proposed patch

Re: [RFC PATCH] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

On Sun, Feb 05, 2017 at 12:10:53AM +0100, Jason A. Donenfeld wrote: > Another thing that might be helpful is that you can let gcc decide on > the alignment, and then optimize appropriately. Check out what we do > with siphash: > >

Re: [PATCH v2] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

On Sat, Feb 04, 2017 at 01:20:38PM -0800, Eric Biggers wrote: > Unfortunately this is still broken, for two different reasons. First, if the > pointers have the same relative misalignment, then 'delta' and 'misalign' will > be set to 0 and long accesses will be used, even though the poi

Re: [PATCH v2] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

Hi Ard, On Thu, Feb 02, 2017 at 03:56:28PM +, Ard Biesheuvel wrote: > + const int size = sizeof(unsigned long); > + int delta = ((unsigned long)dst ^ (unsigned long)src) & (size - 1); > + int misalign = 0; > + > + if (!IS_ENABLED(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS) &&

Re: [RFC PATCH v2 4/4] crypto: aes - add generic time invariant AES for CTR/CCM/GCM

Hi Ard, On Sat, Jan 28, 2017 at 11:33:33PM +, Ard Biesheuvel wrote: > > Note that this only implements AES encryption, which is all we need > for CTR and CBC-MAC. AES decryption can easily be implemented in a > similar way, but is significantly more costly. Is the expectation of decryption

Re: [RFC PATCH] crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic

On Mon, Jan 30, 2017 at 02:11:29PM +, Ard Biesheuvel wrote: > Instead of unconditionally forcing 4 byte alignment for all generic > chaining modes that rely on crypto_xor() or crypto_inc() (which may > result in unnecessary copying of data when the underlying hardware > can perform unaligned

Re: [PATCH] dm: switch dm-verity to async hash crypto API

On Sun, Jan 29, 2017 at 09:39:20AM +0200, Gilad Ben-Yossef wrote: > Hi Odrej, > > On Thu, Jan 26, 2017 at 1:34 PM, Ondrej Mosnáček > wrote: > > Hi Gilad, > > > > 2017-01-24 15:38 GMT+01:00 Gilad Ben-Yossef : > >> - v->tfm =

Re: 4.10 aesni-intel no longer having lrw/ablk_helper dependencies?

On Sun, Jan 29, 2017 at 10:31:59PM +0100, Arkadiusz Miskiewicz wrote: > Hi. > > [arekm@xps ~]$ modinfo --set-version 4.9.6 aesni-intel | grep depends > depends:glue_helper,aes-x86_64,lrw,cryptd,ablk_helper > > [arekm@xps ~]$ modinfo --set-version 4.10.0-rc5-00161-gfd694aaa46c7 aesni- >

Re: [PATCH v5 0/5] Update LZ4 compressor module

On Thu, Jan 26, 2017 at 08:57:30AM +0100, Sven Schmidt wrote: > > This patchset is for updating the LZ4 compression module to a version based > on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast > which provides an "acceleration" parameter as a tradeoff between > high

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

On Thu, Jan 12, 2017 at 01:59:57PM +0100, Ondrej Mosnacek wrote: > 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 >

[PATCH] crypto: testmgr - use kmemdup instead of kmalloc+memcpy

From: Eric Biggers <ebigg...@google.com> It's recommended to use kmemdup instead of kmalloc followed by memcpy. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/crypto/testmgr.c b/cryp

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

On Wed, Dec 14, 2016 at 01:04:04PM +0800, Herbert Xu wrote: > On Tue, Dec 13, 2016 at 06:53:03PM -0800, Andy Lutomirski wrote: > > On Tue, Dec 13, 2016 at 6:48 PM, Andy Lutomirski wrote: > > > The driver put a constant buffer of all zeros on the stack and > > > pointed a

Re: [PATCH v3] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 11:18:32PM +0100, Jason A. Donenfeld wrote: > + for (; data != end; data += sizeof(u64)) { > + m = get_unaligned_le64(data); > + v3 ^= m; > + SIPROUND; > + SIPROUND; > + v0 ^= m; > + } > +#if

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

On Mon, Dec 12, 2016 at 12:55:55PM -0800, Andy Lutomirski wrote: > +int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key, > u8 *da, u8 *sa, u8 priority, > u8 *data, size_t data_len, u8 *mic) > { > - AHASH_REQUEST_ON_STACK(req, tfm_michael); > - struct

Re: [PATCH v2] siphash: add cryptographically secure hashtable function

On Mon, Dec 12, 2016 at 04:48:17AM +0100, Jason A. Donenfeld wrote: > > diff --git a/lib/Makefile b/lib/Makefile > index 50144a3aeebd..71d398b04a74 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \ >sha1.o chacha20.o md5.o

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sun, Dec 11, 2016 at 11:13:55AM -0800, Andy Lutomirski wrote: > On Fri, Dec 9, 2016 at 3:08 PM, Eric Biggers <ebigge...@gmail.com> wrote: > > In the 4.9 kernel, virtually-mapped stacks will be supported and enabled by > > default on x86_64. This has been exposing a number

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 04:16:43PM +0800, Herbert Xu wrote: > Why did you drop me from the CC list when you were replying to > my email? > Sorry --- this thread is Cc'ed to the kernel-hardening mailing list (which was somewhat recently revived), and I replied to the email that reached me from

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 01:37:12PM +0800, Herbert Xu wrote: > On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > > > Herbert, how hard would it be to teach the crypto code to use a more > > sensible data structure than scatterlist and to use coccinelle fix > > this stuff for

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Fri, Dec 09, 2016 at 09:25:38PM -0800, Andy Lutomirski wrote: > > The following crypto drivers initialize a scatterlist to point into an > > ahash_request, which may have been allocated on the stack with > > AHASH_REQUEST_ON_STACK(): > > > > drivers/crypto/bfin_crc.c:351 > >

Re: [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests

On Wed, Dec 07, 2016 at 07:53:51PM +, Ard Biesheuvel wrote: > Does this help at all? > > diff --git a/crypto/testmgr.c b/crypto/testmgr.c > index 670893bcf361..59e67f5b544b 100644 > --- a/crypto/testmgr.c > +++ b/crypto/testmgr.c > @@ -63,7 +63,7 @@ int alg_test(const char *driver, const char

Re: Crash in crypto mcryptd

On Thu, Dec 01, 2016 at 05:47:02PM -0800, Tim Chen wrote: > On Thu, 2016-12-01 at 19:00 -0500, Mikulas Patocka wrote: > > Hi > > > > There is a bug in mcryptd initialization. > > > > This is a test module that tries various hash algorithms. When you load  > > the module with "insmod test.ko

[PATCH] crypto: acomp - don't use stack buffer in test_acomp()

rypto: acomp - update testmgr with support for acomp") Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index ded50b6..aca1b7b 100644 --- a/crypto

Re: vmalloced stacks and scatterwalk_map_and_copy()

al request data. As this check is now triggering BUG checks > due to the vmalloced stack code, I'm removing it. > > Reported-by: Eric Biggers <ebigg...@google.com> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> > > diff --git a/crypto/scatterwalk.c b/crypto/s

Re: [PATCH 2/2] fscrypto: don't use on-stack buffer for key derivation

On Tue, Nov 15, 2016 at 11:47:04AM -0500, Theodore Ts'o wrote: > On Thu, Nov 03, 2016 at 03:03:02PM -0700, Eric Biggers wrote: > > With the new (in 4.9) option to use a virtually-mapped stack > > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for > > the s

Re: [v2 PATCH 7/16] crypto: simd - Add simd skcipher helper

On Sun, Nov 13, 2016 at 07:45:38PM +0800, Herbert Xu wrote: > This patch adds the simd skcipher helper which is meant to be > a replacement for ablk helper. It replaces the underlying blkcipher > interface with skcipher, and also presents the top-level algorithm > as an skcipher. I assume this

Re: [v2 PATCH 4/16] crypto: xts - Convert to skcipher

On Sun, Nov 13, 2016 at 07:45:35PM +0800, Herbert Xu wrote: > +static int do_encrypt(struct skcipher_request *req, int err) > +{ > + struct rctx *rctx = skcipher_request_ctx(req); > + struct skcipher_request *subreq; > + > + subreq = >subreq; > + > + while (!err && rctx->left) { >

Re: [v2 PATCH 6/16] crypto: cryptd - Add support for skcipher

On Sun, Nov 13, 2016 at 07:45:37PM +0800, Herbert Xu wrote: > +static void cryptd_skcipher_encrypt(struct crypto_async_request *base, > + int err) > +{ > + struct skcipher_request *req = skcipher_request_cast(base); > + struct cryptd_skcipher_request_ctx

Re: [v2 PATCH 1/16] crypto: skcipher - Add skcipher walk interface

Hi Herbert, On Sun, Nov 13, 2016 at 07:45:32PM +0800, Herbert Xu wrote: > +int skcipher_walk_done(struct skcipher_walk *walk, int err) > +{ > + unsigned int nbytes = 0; > + unsigned int n = 0; > + > + if (likely(err >= 0)) { > + n = walk->nbytes - err; > +

Re: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access

On Tue, Nov 08, 2016 at 08:52:39AM +0100, Martin Willi wrote: > > > Not sure what the exact alignment rules for key/iv are, but maybe we > want to replace the same function in chacha20_generic.c as well? > > Martin chacha20-generic provides a blkcipher API and sets an alignmask of sizeof(u32)

Re: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access

. Donenfeld <ja...@zx2c4.com> > --- Reviewed-by: Eric Biggers <ebigg...@google.com> Nit: the subject line is a little unclear about what was changed. "make generic C faster on chips with slow unaligned access" would be better. -- To unsubscribe from this list: send the lin

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 07, 2016 at 08:02:35PM +0100, Jason A. Donenfeld wrote: > On Mon, Nov 7, 2016 at 7:26 PM, Eric Biggers <ebigg...@google.com> wrote: > > > > I was not referring to any users in particular, only what users could do. > > As an > > example, if you did

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Mon, Nov 07, 2016 at 07:08:22PM +0100, Jason A. Donenfeld wrote: > Hmm... The general data flow that strikes me as most pertinent is > something like: > > struct sk_buff *skb = get_it_from_somewhere(); > skb = skb_share_check(skb, GFP_ATOMIC); > num_frags = skb_cow_data(skb, ..., ...); >

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Thu, Nov 03, 2016 at 11:20:08PM +0100, Jason A. Donenfeld wrote: > Hi David, > > On Thu, Nov 3, 2016 at 6:08 PM, David Miller wrote: > > In any event no piece of code should be doing 32-bit word reads from > > addresses like "x + 3" without, at a very minimum, going

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 08:57:49PM -0700, Andy Lutomirski wrote: > > The crypto request objects can live on the stack just fine. It's the > request buffers that need to live elsewhere (or the alternative > interfaces can be used, or the crypto core code can start using > something other than

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 02:12:07PM -0700, Eric Biggers wrote: > On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > > > Also, Herbert, it seems like the considerable majority of the crypto > > code is acting on kernel virtual memory addresses and does so

[PATCH 2/2] fscrypto: don't use on-stack buffer for key derivation

operation used to derive the per-file key. Fix it by using a heap buffer. This bug could most easily be observed in a CONFIG_DEBUG_SG kernel because this allowed the BUG in sg_set_buf() to be triggered. Signed-off-by: Eric Biggers <ebigg...@google.com> --- fs/crypto/keyinfo.

[PATCH 1/2] fscrypto: don't use on-stack buffer for filename encryption

the padded filename. Fix it by encrypting the filename in-place in the output buffer, thereby making the temporary buffer unnecessary. This bug could most easily be observed in a CONFIG_DEBUG_SG kernel because this allowed the BUG in sg_set_buf() to be triggered. Signed-off-by: Eric Biggers <eb

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based

vmalloced stacks and scatterwalk_map_and_copy()

Hello, I hit the BUG_ON() in arch/x86/mm/physaddr.c:26 while testing some crypto code in an x86_64 kernel with CONFIG_DEBUG_VIRTUAL=y and CONFIG_VMAP_STACK=y: /* carry flag will be set if starting x was >= PAGE_OFFSET */ VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x)); The

Re: [PATCH 1/16] crypto: skcipher - Add skcipher walk interface

Hi Herbert, just a few preliminary comments. I haven't made it through everything yet. On Wed, Nov 02, 2016 at 07:19:02AM +0800, Herbert Xu wrote: > +static int skcipher_walk_first(struct skcipher_walk *walk) > +{ > + if (WARN_ON_ONCE(in_irq())) > + return -EDEADLK; > + > +

Alignment of shash input buffers?

Hi, I'm having trouble understanding how alignment of shash input buffers is supposed to work. If you pass crypto_shash_update() a buffer that is not aligned to the shash algorithm's alignmask, it will call the underlying ->update() function twice, once with a temporary aligned buffer and once

[PATCH] crypto: skcipher - Get rid of crypto_grab_skcipher2()

Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher interface"), crypto_grab_skcipher2() and crypto_grab_skcipher() are equivalent. So switch callers of crypto_grab_skcipher2() to crypto_grab_skcipher() and remove it. Signed-off-by: Eric Biggers <ebigg.

[PATCH] crypto: skcipher - Get rid of crypto_spawn_skcipher2()

Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher interface"), crypto_spawn_skcipher2() and crypto_spawn_skcipher() are equivalent. So switch callers of crypto_spawn_skcipher2() to crypto_spawn_skcipher() and remove it. Signed-off-by: Eric Biggers <ebigg.

Re: [PATCH] crypto: cmac - fix alignment of 'consts'

On Mon, Oct 10, 2016 at 10:51:14AM -0700, Joe Perches wrote: > > Hey Eric. > > I don't see any PTR_ALIGN uses in crypto/ or drivers/crypto/ that > use a bitwise or, just mask + 1, but I believe the effect is the > same. Anyway, your choice, but I think using min is clearer. > > cheers, Joe

Re: [PATCH] crypto: cmac - fix alignment of 'consts'

On Mon, Oct 10, 2016 at 10:29:55AM -0700, Joe Perches wrote: > On Mon, 2016-10-10 at 10:15 -0700, Eric Biggers wrote: > > The per-transform 'consts' array is accessed as __be64 in > > crypto_cmac_digest_setkey() but was only guaranteed to be aligned to > > __alignof__(long).

[PATCH] crypto: cmac - fix alignment of 'consts'

The per-transform 'consts' array is accessed as __be64 in crypto_cmac_digest_setkey() but was only guaranteed to be aligned to __alignof__(long). Fix this by aligning it to __alignof__(__be64). Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/cmac.c | 13 +

[PATCH] crypto: cmac - return -EINVAL if block size is unsupported

ons. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/cmac.c | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/cmac.c b/crypto/cmac.c index 7a8bfbd..b6c4059 100644 --- a/crypto/cmac.c +++ b/crypto/cmac.c @@ -243,6 +243,7 @@ static int cmac_create(struct crypto_templ

[PATCH] crypto: skcipher - Remove unused crypto_lookup_skcipher() declaration

The definition of crypto_lookup_skcipher() was already removed in commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher interface"). So the declaration should be removed too. Signed-off-by: Eric Biggers <ebigg...@google.com> --- include/crypto/internal/skcipher.

[PATCH] crypto: api - Remove no-op exit_ops code

crypto_exit_cipher_ops() and crypto_exit_compress_ops() are no-ops and have been for a long time, so remove them. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/api.c | 20 ++-- crypto/cipher.c | 4 crypto/compress.c | 4 crypto/internal.

[PATCH RESEND] crypto: doc - fix documentation for bulk registration functions

Update the documentation for crypto_register_algs() and crypto_unregister_algs() to match the actual behavior. Signed-off-by: Eric Biggers <ebigg...@google.com> --- Documentation/DocBook/crypto-API.tmpl | 38 --- 1 file changed, 26 insertions(+), 12 del

[PATCH] crypto: doc - fix documentation for bulk registration functions

Update the documentation for crypto_register_algs() and crypto_unregister_algs() to match the actual behavior. Signed-off-by: Eric Biggers <ebigg...@google.com> --- Documentation/DocBook/crypto-API.tmpl | 38 --- 1 file changed, 26 insertions(+), 12 del

[PATCH] crypto: document correct return value for request allocation

Signed-off-by: Eric Biggers <ebigge...@gmail.com> --- Documentation/DocBook/crypto-API.tmpl | 6 +++--- include/crypto/aead.h | 3 +-- include/crypto/hash.h | 3 +-- include/crypto/skcipher.h | 3 +-- include/linux/crypto.h| 3

<    1   2   3   4   5