[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

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: [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 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 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: [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: [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] 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

[PATCH 1/2] crypto: kpp - constify buffer passed to crypto_kpp_set_secret()

From: Eric Biggers <ebigg...@google.com> Constify the buffer passed to crypto_kpp_set_secret() and kpp_alg.set_secret, since it is never modified. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/dh.c | 3 ++- c

[PATCH 2/2] crypto: testmgr - constify all test vectors

From: Eric Biggers <ebigg...@google.com> Cryptographic test vectors should never be modified, so constify them to enforce this at both compile-time and run-time. This moves a significant amount of data from .data to .rodata when the crypto tests are enabled. Signed-off-by: Eric Biggers

[PATCH 0/2] crypto: constify test vectors

From: Eric Biggers <ebigg...@google.com> These two patches mark all the cryptographic test vectors as 'const'. This has several potential advantages and moves a large amount of data from .data to .rodata when the tests are enabled. The second patch does the real work; the first just pr

[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 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 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

[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 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

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: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 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.] > > >

[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 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: 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.

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

[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: 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 +

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).

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 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 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] 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 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: 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

[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: [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: [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 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 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: [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

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: 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

[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

[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.

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

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; > + > +

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: [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: [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: [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 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: 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 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: [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] 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: 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: [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 >

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: 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: crypto: out-of-bounds write in pre_crypt

Hi Dmitry, On Thu, Mar 23, 2017 at 11:51:30AM +0100, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer. > init_crypt ignores kmalloc failure, which later leads to out-of-bounds > writes in ptr_crypt. On commit >

Re: [PATCH] md5: remove from lib and only live in crypto

e patch itself looks good to me, and you can add Reviewed-by: Eric Biggers <ebigg...@google.com> There is a small issue, though, which is that currently cryptodev/master (where this patch would be applied to) still has md5_transform() in drivers/char/random.c, because cryptodev/master is based

[PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure

From: Eric Biggers <ebigg...@google.com> In the generic XTS and LRW algorithms, for input data > 128 bytes, a temporary buffer is allocated to hold the values to be XOR'ed with the data before and after encryption or decryption. If the allocation fails, the fixed-size buffer

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

Hi Ondrej, On Thu, Mar 30, 2017 at 09:25:35PM +0200, Ondrej Mosnacek wrote: > The gf128mul_x_ble function is currently defined in gf128mul.c, because > it depends on the gf128mul_table_be multiplication table. > > However, since the function is very small and only uses two values from > the

Re: [PATCH 0/7] crypto: aes - allow generic AES to be omitted

On Tue, Mar 28, 2017 at 09:51:54AM +0100, Ard Biesheuvel wrote: > On 28 March 2017 at 06:43, Eric Biggers <ebigge...@gmail.com> wrote: > > > > Just a thought: how about renaming CRYPTO_AES to CRYPTO_AES_GENERIC, then > > renaming what you called CRYPTO_NEED_A

Re: [PATCH 0/7] crypto: aes - allow generic AES to be omitted

Hi Ard, On Sun, Mar 26, 2017 at 07:49:01PM +0100, Ard Biesheuvel wrote: > The generic AES driver uses 16 lookup tables of 1 KB each, and has > encryption and decryption routines that are fully unrolled. Given how > the dependencies between this code and other drivers are declared in > Kconfig

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

e, the speed of the generic 'xts(aes)' implementation > increased from ~225 MiB/s 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). > Reviewed-by: Eric Biggers <ebigg...@google.com> Thanks, - Eric

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

. > > Signed-off-by: Ondrej Mosnacek <omosna...@gmail.com> > Cc: Eric Biggers <ebigg...@google.com> Reviewed-by: Eric Biggers <ebigg...@google.com> Also, I realized that for gf128mul_x_lle() now that we aren't using the table we don't need to shift '_tt' but rather

Re: [RFC PATCH v1 1/1] crypto: algif_compression - User-space interface for compression

On Fri, Apr 14, 2017 at 12:04:54AM +0530, Abed Kamaluddin wrote: > crypto: algif_compression - User-space interface for compression > > This patch adds af_alg plugin for compression algorithms of type scomp/acomp > registered to the kernel crypto layer. > > The user needs to set operation

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

Hi Stephan, On Thu, Apr 20, 2017 at 08:38:30PM +0200, Stephan Müller wrote: > > > > By the way: do we really need this in the kernel at all, given that it's > > just doing some math on data which userspace has access to? > > It is the question about how we want the keys subsystem to operate.

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

Hi Stephan, On Thu, Apr 20, 2017 at 03:27:17PM +0200, Stephan Müller wrote: > Am Donnerstag, 20. April 2017, 07:46:31 CEST schrieb Eric Biggers: > > Hi Eric, > > > From: Eric Biggers <ebigg...@google.com> > > > > The result of the Diffie-Hellman computati

[PATCH 1/5] KEYS: DH: forbid using digest_null as the KDF hash

From: Eric Biggers <ebigg...@google.com> Requesting "digest_null" in the keyctl_kdf_params caused an infinite loop in kdf_ctr() because the "null" hash has a digest size of 0. Fix it by rejecting hash algorithms with a digest size of 0. Signed-off-by: Eric Bi

[PATCH 2/5] KEYS: DH: don't feed uninitialized "otherinfo" into KDF

From: Eric Biggers <ebigg...@google.com> If userspace called KEYCTL_DH_COMPUTE with kdf_params containing NULL otherinfo but nonzero otherinfolen, the kernel would allocate a buffer for the otherinfo, then feed it into the KDF without initializing it. Fix this by always doing the cop

[PATCH 5/5] KEYS: DH: add __user annotations to keyctl_kdf_params

From: Eric Biggers <ebigg...@google.com> Signed-off-by: Eric Biggers <ebigg...@google.com> --- include/uapi/linux/keyctl.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h index 201c6644b237..ef16df0

[PATCH 4/5] KEYS: DH: ensure the KDF counter is properly aligned

From: Eric Biggers <ebigg...@google.com> Accessing a 'u8[4]' through a '__be32 *' violates alignment rules. Just make the counter a __be32 instead. Signed-off-by: Eric Biggers <ebigg...@google.com> --- security/keys/dh.c | 16 +++- 1 file changed, 3 insertions(+),

[PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension

This patch series fixes several bugs in the KDF extension to keyctl_dh_compute() currently sitting in keys-next: a way userspace could cause an infinite loop, two ways userspace could cause the use of uninitialized memory, a misalignment, and missing __user annotations. Eric Biggers (5): KEYS

[PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

From: Eric Biggers <ebigg...@google.com> The result of the Diffie-Hellman computation may be shorter than the input prime number. Only calculate the KDF over the actual result; don't include additional uninitialized memory. Signed-off-by: Eric Biggers <ebigg...@google.com> --- s

Re: [PATCH v5 0/4] gf128mul refactoring

tch gf128mul_x_ble to le128 > crypto: glue_helper - remove the le128_gf128mul_x_ble function > crypto: xts - drop gf128mul dependency These all look good to me, and you can add Reviewed-by: Eric Biggers <ebigg...@google.com> to the patches. I think the change to le128 is an improve

Re: [PATCH v5 2/5] lib: Add zstd modules

On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: > > It can compress at speeds approaching lz4, and quality approaching lzma. Well, for a very loose definition of "approaching", and certainly not at the same time. I doubt there's a use case for using the highest compression levels

Re: [PATCH v5 2/5] lib: Add zstd modules

On Thu, Aug 10, 2017 at 07:32:18AM -0400, Austin S. Hemmelgarn wrote: > On 2017-08-10 04:30, Eric Biggers wrote: > >On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: > >> > >>It can compress at speeds approaching lz4, and quality approaching lzma. &g

Re: [PATCH v5 2/5] lib: Add zstd modules

On Thu, Aug 10, 2017 at 10:57:01AM -0400, Austin S. Hemmelgarn wrote: > Also didn't think to mention this, but I could see the max level > being very popular for use with SquashFS root filesystems used in > LiveCD's. Currently, they have to decide between read performance > and image size, while

Re: [PATCH v5 2/5] lib: Add zstd modules

On Thu, Aug 10, 2017 at 01:41:21PM -0400, Chris Mason wrote: > On 08/10/2017 04:30 AM, Eric Biggers wrote: > >On Wed, Aug 09, 2017 at 07:35:53PM -0700, Nick Terrell wrote: > > >>The memory reported is the amount of memory the compressor requests. > >> > >>|

Re: [PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

Hi Stephan, On Thu, Jul 13, 2017 at 04:54:55PM +0200, Stephan Müller wrote: > Am Mittwoch, 12. Juli 2017, 23:00:32 CEST schrieb Eric Biggers: > > Hi Herbert, > > This patch adds a second KDF to the kernel -- the first is found in the keys > subsystem. > > Th

Re: [PATCH 1/6] fscrypt: add v2 encryption context and policy

Hi Michael, On Thu, Jul 13, 2017 at 03:29:44PM -0700, Michael Halcrow wrote: > On Wed, Jul 12, 2017 at 02:00:30PM -0700, Eric Biggers wrote: > > From: Eric Biggers <ebigg...@google.com> > > > > Currently, the fscrypt_context (i.e. the encryption xattr) does not >

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On Tue, Jul 11, 2017 at 11:53:11AM -0700, Dave Watson wrote: > On 07/11/17 08:29 AM, Steffen Klassert wrote: > > Sorry for replying to old mail... > > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx) > > > +{ > > > > ... > > > > > + > > > + if (!sw_ctx->aead_send) { > > > +

Re: [PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

On Fri, Jul 14, 2017 at 09:24:40AM -0700, Michael Halcrow wrote: > > +static int hkdf_expand(struct crypto_shash *hmac, u8 context, > > + const u8 *info, unsigned int infolen, > > + u8 *okm, unsigned int okmlen) > > +{ > > + SHASH_DESC_ON_STACK(desc, hmac); > >

Re: [PATCH v4 0/8] crypto: aes - retire table based generic AES

On Mon, Jul 24, 2017 at 07:59:43AM +0100, Ard Biesheuvel wrote: > On 18 July 2017 at 13:06, Ard Biesheuvel wrote: > > The generic AES driver uses 16 lookup tables of 1 KB each, and has > > encryption and decryption routines that are fully unrolled. Given how > > the

[PATCH v2 3/7] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

From: Eric Biggers <ebigg...@google.com> By design, the keys which userspace provides in the keyring are not used to encrypt data directly. Instead, a KDF (Key Derivation Function) is used to derive a unique encryption key for each inode, given a "master" key and a nonce.

[PATCH v2 1/7] fscrypt: add v2 encryption context and policy

From: Eric Biggers <ebigg...@google.com> Currently, the fscrypt_context (i.e. the encryption xattr) does not contain a cryptographically secure identifier for the master key's payload. Therefore it's not possible to verify that the correct key was supplied, which is problematic in mult

[PATCH v2 0/7] fscrypt: key verification and KDF improvement

From: Eric Biggers <ebigg...@google.com> This patch series solves two major problems which filesystem-level encryption has currently. First, the user-supplied master keys are not verified, which means a malicious user can provide the wrong key for another user's file and cause a DOS

[PATCH v2 5/7] fscrypt: verify that the correct master key was supplied

From: Eric Biggers <ebigg...@google.com> Currently, while a fscrypt master key is required to have a certain description in the keyring, its payload is never verified to be correct. While sufficient for well-behaved userspace, this is insecure in a multi-user system where a user has been

[PATCH v2 7/7] fscrypt: for v2 policies, support "fscrypt:" key prefix only

From: Eric Biggers <ebigg...@google.com> Since v2 encryption policies are opt-in, take the opportunity to also drop support for the legacy filesystem-specific key description prefixes "ext4:", "f2fs:", and "ubifs:", instead requiring the generic prefix "fs

[PATCH v2 6/7] fscrypt: cache the HMAC transform for each master key

From: Eric Biggers <ebigg...@google.com> Now that we have a key_hash field which securely identifies a master key payload, introduce a cache of the HMAC transforms for the master keys currently in use for inodes using v2+ encryption policies. The entries in this cache are called '

Re: [PATCH 5/6] fscrypt: cache the HMAC transform for each master key

On Mon, Jul 17, 2017 at 10:45:51AM -0700, Michael Halcrow wrote: > > +/* > > + * Get the fscrypt_master_key identified by the specified v2+ encryption > > + * context, or create it if not found. > > + * > > + * Returns the fscrypt_master_key with a reference taken, or an ERR_PTR(). > > + */ > >

[PATCH 2/6] fscrypt: rename ->ci_master_key to ->ci_master_key_descriptor

From: Eric Biggers <ebigg...@google.com> In struct fscrypt_info, ->ci_master_key is the master key descriptor, not the master key itself. In preparation for introducing a struct fscrypt_master_key and making ->ci_master_key point to it, rename the existing -&g

[PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

From: Eric Biggers <ebigg...@google.com> By design, the keys which userspace provides in the keyring are not used to encrypt data directly. Instead, a KDF (Key Derivation Function) is used to derive a unique encryption key for each inode, given a "master" key and a nonce.

[PATCH 4/6] fscrypt: verify that the correct master key was supplied

From: Eric Biggers <ebigg...@google.com> Currently, while a fscrypt master key is required to have a certain description in the keyring, its payload is never verified to be correct. While sufficient for well-behaved userspace, this is insecure in a multi-user system where a user has been

  1   2   3   4   5   >