Re: [PATCH] crypto: remove Speck

Hi Jason, On Tue, Apr 24, 2018 at 06:18:26PM +0200, Jason A. Donenfeld wrote: > This NSA-designed cipher was rejected for inclusion in international > standards by ISO/IEC. Before anyone actually starts using it by > accident, let's just not ship it at all. > > Signed-off-by: Jason A. Donenfeld

Re: [PATCH v2 0/5] crypto: Speck support

Hi Jason, On Tue, Apr 24, 2018 at 06:11:26PM +0200, Jason A. Donenfeld wrote: > Can we please not Speck? > > It was just rejected by the ISO/IEC. > > https://twitter.com/TomerAshur/status/988659711091228673 So, what do you propose replacing it with? As I explained in the patch, the purpose of

[PATCH] crypto: api - fix finding algorithm currently being tested

From: Eric Biggers <ebigg...@google.com> Commit eb02c38f0197 ("crypto: api - Keep failed instances alive") is making allocating crypto transforms sometimes fail with ELIBBAD, when multiple processes try to access encrypted files with fscrypt for the first time since bo

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

On Mon, Apr 16, 2018 at 07:34:29PM +, Yann Collet wrote: > Hi Singh > > I don't have any strong opinion on this topic. > > You made your case clear: > your variant trades a little bit of speed for a little bit more compression > ratio. > In the context of zram, it makes sense, and I would

Re: [PATCH] crypto: drbg - set freed buffers to NULL

On Wed, Apr 11, 2018 at 04:31:01PM +0200, Stephan Müller wrote: > Sorry, this time with the proper subject line. > > ---8<--- > > During freeing of the internal buffers used by the DRBG, set the pointer > to NULL. It is possible that the context with the freed buffers is > reused. In case of an

Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation

On Mon, Apr 09, 2018 at 10:58:08AM +0200, Steffen Klassert wrote: > On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote: > > On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote: > > > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > > >

Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation

On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote: > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > > From: Eric Biggers <ebigg...@google.com> > > > > If the pcrypt template is used multiple times in an algorithm, then a > > deadlock oc

Re: INFO: task hung in exit_aio

[+Cc linux-crypto] On Sun, Dec 10, 2017 at 05:33:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 82bcf1def3b5f1251177ad47c44f7e17af039b4b > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output

[PATCH] sunrpc: remove incorrect HMAC request initialization

on") Cc: sta...@vger.kernel.org Signed-off-by: Eric Biggers <ebigg...@google.com> --- net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c index 12649c9fedab..865

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

[+Cc linux-crypto] Hi Yael, On Sun, Mar 25, 2018 at 07:41:30PM +0100, Yael Chemla wrote: > Allow parallel processing of bio blocks by moving to async. completion > handling. This allows for better resource utilization of both HW and > software based hash tfm and therefore better performance

Re: [PATCH] crypto: ctr: avoid VLA use

On Wed, Mar 14, 2018 at 02:17:30PM +0100, Salvatore Mesoraca wrote: > All ciphers implemented in Linux have a block size less than or > equal to 16 bytes and the most demanding hw require 16 bits > alignment for the block buffer. > We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bits >

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Benjamin, On Wed, Mar 07, 2018 at 12:50:08PM +0100, Benjamin Warnke wrote: > Hi Eric, > > > On 06.03.2018 at 23:13, Eric Biggers wrote: > > > > Hi Benjamin, > > > > On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: > >> Cu

[RFC PATCH] crypto: pcrypt - forbid recursive instantiation

From: Eric Biggers <ebigg...@google.com> If the pcrypt template is used multiple times in an algorithm, then a deadlock occurs because all pcrypt instances share the same padata_instance, which completes requests in the order submitted. That is, the inner pcrypt request waits for the

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Benjamin, On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: > Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM > compresses each page individually. As a result the compression algorithm is > forced to use a very small sliding window. None of the available

Re: [RFC PATCH cryptodev] crypto: des3_ede_skciphers[] can be static

ipher = { > } > }; > > -struct skcipher_alg des3_ede_skciphers[] = { > +static struct skcipher_alg des3_ede_skciphers[] = { > { > .base.cra_name = "ecb(des3_ede)", > .base.cra_driver_name = "ecb-des3_ede-asm", Acked-by: Eric Biggers <ebigg...@google.com> Thanks!

[PATCH] fscrypt: add Speck128/256 support

also because CRYPTO_SPECK just refers to the generic implementation, which won't be fast enough for many users; in practice, they'll need to enable a vectorized implementation such as CRYPTO_SPECK_NEON to get acceptable performance. Signed-off-by: Eric Biggers <ebigg...@google.com> --- Docume

[PATCH -stable 2/2] crypto: hash - prevent using keyed hashes without setting key

From: Eric Biggers <ebigg...@google.com> commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream. [Please apply to 4.9-stable.] Currently, almost none of the keyed hash algorithms check whether a key has been set before proceeding. Some algorithms are okay with this and will effectivel

[PATCH -stable 1/2] crypto: hash - annotate algorithms taking optional key

From: Eric Biggers <ebigg...@google.com> commit a208fa8f33031b9e0aba44c7d1b7e68eb0cbd29e upstream. [Please apply to 4.9-stable.] We need to consistently enforce that keyed hashes cannot be used without setting the key. To do this we need a reliable way to determine whether a give

Re: [PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported

Hi David, On Thu, Feb 08, 2018 at 03:07:30PM +, David Howells wrote: > Eric Biggers <ebigge...@gmail.com> wrote: > > > The X.509 parser mishandles the case where the certificate's signature's > > hash algorithm is not available in the crypto API. In this case,

[PATCH 13/30] crypto: x86/twofish-avx - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the AVX implementation of Twofish from the (deprecated) ablkcipher and blkcipher interfaces over to the skcipher interface. Note that this includes replacing the use of ablk_helper with crypto_simd. Signed-off-by: Eric Biggers <ebigg...@g

[PATCH 26/30] crypto: xts - remove xts_crypt()

From: Eric Biggers <ebigg...@google.com> Now that all users of xts_crypt() have been removed in favor of the XTS template wrapping an ECB mode algorithm, remove xts_crypt(). Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/xts.c

[PATCH 27/30] crypto: lrw - remove lrw_crypt()

From: Eric Biggers <ebigg...@google.com> Now that all users of lrw_crypt() have been removed in favor of the LRW template wrapping an ECB mode algorithm, remove lrw_crypt(). Also remove crypto/lrw.h as that is no longer needed either; and fold 'struct lrw_table_ctx' into 'struc

[PATCH 12/30] crypto: x86/twofish-avx - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-twofish-avx algorithm

[PATCH 24/30] crypto: x86/camellia - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the x86 asm implementation of Camellia from the (deprecated) blkcipher interface over to the skcipher interface. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/camellia_

[PATCH 29/30] crypto: x86/glue_helper - rename glue_skwalk_fpu_begin()

From: Eric Biggers <ebigg...@google.com> There are no users of the original glue_fpu_begin() anymore, so rename glue_skwalk_fpu_begin() to glue_fpu_begin() so that it matches glue_fpu_end() again. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/cast

[PATCH 21/30] crypto: x86/camellia-aesni-avx2 - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-camellia-aesni-avx2 alg

[PATCH 15/30] crypto: x86/cast5-avx - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the AVX implementation of CAST5 from the (deprecated) ablkcipher and blkcipher interfaces over to the skcipher interface. Note that this includes replacing the use of ablk_helper with crypto_simd. Signed-off-by: Eric Biggers <ebigg...@g

[PATCH 18/30] crypto: x86/blowfish: convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the x86 asm implementation of Blowfish from the (deprecated) blkcipher interface over to the skcipher interface. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/blowfish_

[PATCH 19/30] crypto: x86/des3_ede - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the x86 asm implementation of Triple DES from the (deprecated) blkcipher interface over to the skcipher interface. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/des3_ede_

[PATCH 28/30] crypto: x86/glue_helper - remove blkcipher_walk functions

From: Eric Biggers <ebigg...@google.com> Now that all glue_helper users have been switched from the blkcipher interface over to the skcipher interface, remove the versions of the glue_helper functions that handled the blkcipher interface. Signed-off-by: Eric Biggers <ebigg...@g

[PATCH 30/30] crypto: ablk_helper - remove ablk_helper

From: Eric Biggers <ebigg...@google.com> All users of ablk_helper have been converted over to crypto_simd, so remove ablk_helper. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/Kconfig | 4 -- crypto/Makefile | 1 - crypto/ablk_helper.c

[PATCH 16/30] crypto: x86/cast6-avx - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-cast6-avx algorithm whi

[PATCH 23/30] crypto: x86/camellia - remove XTS algorithm

From: Eric Biggers <ebigg...@google.com> The XTS template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic XTS code themselves via xts_crypt(). Remove the xts-camellia-asm algorithm

[PATCH 25/30] crypto: x86/camellia-aesni-avx,avx2 - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the AESNI AVX and AESNI AVX2 implementations of Camellia from the (deprecated) ablkcipher and blkcipher interfaces over to the skcipher interface. Note that this includes replacing the use of ablk_helper with crypto_simd. Signed-off-by

[PATCH 17/30] crypto: x86/cast6-avx - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the AVX implementation of CAST6 from the (deprecated) ablkcipher and blkcipher interfaces over to the skcipher interface. Note that this includes replacing the use of ablk_helper with crypto_simd. Signed-off-by: Eric Biggers <ebigg...@g

[PATCH 22/30] crypto: x86/camellia - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-camellia-asm algorithm

[PATCH 20/30] crypto: x86/camellia-aesni-avx - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-camellia-aesni alg

[PATCH 03/30] crypto: x86/serpent-sse2 - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-serpent-sse2 algorithm

[PATCH 07/30] crypto: x86/serpent-avx - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-serpent-avx algorithm

[PATCH 02/30] crypto: x86/glue_helper - add skcipher_walk functions

From: Eric Biggers <ebigg...@google.com> Add ECB, CBC, and CTR functions to glue_helper which use skcipher_walk rather than blkcipher_walk. This will allow converting the remaining x86 algorithms from the blkcipher interface over to the skcipher interface, after which we'll be able to

[PATCH 11/30] crypto: x86/twofish-3way - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the 3-way implementation of Twofish from the (deprecated) blkcipher interface over to the skcipher interface. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/twofish_glue_

[PATCH 04/30] crypto: x86/serpent-sse2 - remove XTS algorithm

From: Eric Biggers <ebigg...@google.com> The XTS template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic XTS code themselves via xts_crypt(). Remove the xts-serpent-sse2 algorithm

[PATCH 05/30] crypto: x86/serpent-sse2 - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the SSE2 implementation of Serpent from the (deprecated) ablkcipher and blkcipher interfaces over to the skcipher interface. Note that this includes replacing the use of ablk_helper with crypto_simd. Signed-off-by: Eric Biggers

[PATCH 09/30] crypto: x86/twofish-3way - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-twofish-3way algorithm

[PATCH 10/30] crypto: x86/twofish-3way - remove XTS algorithm

From: Eric Biggers <ebigg...@google.com> The XTS template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic XTS code themselves via xts_crypt(). Remove the xts-twofish-3way algorithm

[PATCH 06/30] crypto: x86/serpent-avx2 - remove LRW algorithm

From: Eric Biggers <ebigg...@google.com> The LRW template now wraps an ECB mode algorithm rather than the block cipher directly. Therefore it is now redundant for crypto modules to wrap their ECB code with generic LRW code themselves via lrw_crypt(). Remove the lrw-serpent-avx2 algorithm

[PATCH 00/30] crypto: x86 glue code cleanup/conversion

, during which I found a bug in ecb-cast5-avx which this series fixes as well. The overall diff is about 3100 lines of code removed, mainly due to the ablk_helper => crypto_simd conversions and removing the unnecessary LRW and XTS implementations. Eric Biggers (30): crypto: simd - allow register

[PATCH 01/30] crypto: simd - allow registering multiple algorithms at once

From: Eric Biggers <ebigg...@google.com> Add a function to crypto_simd that registers an array of skcipher algorithms, then allocates and registers the simd wrapper algorithms for them. It assumes the naming scheme where the names of the underlying algorithms are prefixed with two under

[PATCH 08/30] crypto: x86/serpent-avx,avx2 - convert to skcipher interface

From: Eric Biggers <ebigg...@google.com> Convert the AVX and AVX2 implementations of Serpent from the (deprecated) ablkcipher and blkcipher interfaces over to the skcipher interface. Note that this includes replacing the use of ablk_helper with crypto_simd. Signed-off-by: Eric Biggers

Re: [RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers [ver #2]

Hi David, On Thu, Feb 15, 2018 at 10:53:49PM +, David Howells wrote: > /* > + * Free up the buffer. > + */ > +static void big_key_free_buffer(struct big_key_buf *buf) > +{ > + unsigned int i; > + > + vunmap(buf->virt); > + for (i = 0; i < buf->nr_pages; i++) > + if

Re: [PATCH v3 2/3] MIPS: crypto: Add crc32 and crc32c hw accelerated module

On Fri, Feb 09, 2018 at 10:11:06PM +, James Hogan wrote: > +static struct shash_alg crc32_alg = { > + .digestsize = CHKSUM_DIGEST_SIZE, > + .setkey = chksum_setkey, > + .init = chksum_init, > + .update

Re: [RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers

Hi David, On Thu, Feb 15, 2018 at 03:54:26PM +, David Howells wrote: > kmalloc() can't always allocate large enough buffers for big_key to use for > crypto (1MB + some metadata) so we cannot use that to allocate the buffer. > Further, vmalloc'd pages can't be passed to sg_init_one() and the

[PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

possible users should use Speck128-XTS, but even that may be too slow on some processors; Speck64-XTS can be faster. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/arm/crypto/Kconfig | 6 + arch/arm/crypto/Makefile | 2 + arch/arm/crypto/speck-neon-core.S

[PATCH v3 5/5] crypto: speck - add test vectors for Speck64-XTS

block size. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 9 + crypto/testmgr.h | 671 +++ 2 files changed, 680 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index e011a347d51b..9f82e7bc9c56

[PATCH v3 4/5] crypto: speck - add test vectors for Speck128-XTS

Add test vectors for Speck128-XTS, generated in userspace using C code. The inputs were borrowed from the AES-XTS test vectors. Both xts(speck128-generic) and xts-speck128-neon pass these tests. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 9 + crypto/tes

[PATCH v3 0/5] crypto: Speck support

implementation can be added later if there is interest though. Changed since v2: - Fix __speck64_xts_crypt() to work on big endian CPUs. Changed since v1: - Use the word order recommended by the Speck authors. All test vectors were updated. Eric Biggers (5): crypto: add support for the Speck

[PATCH v3 1/5] crypto: add support for the Speck block cipher

in a correspondence with them. The test vectors are taken from the original paper but were mapped to byte arrays using the recommended byte and word orders. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/Kconfig | 14 +++ crypto/Makefile | 1 + crypto/speck.c

[PATCH v3 2/5] crypto: speck - export common helpers

le, while the generic encryption and decryption functions are needed as fallbacks and for the XTS tweak encryption. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/speck.c | 90 +++--- include/crypto/speck.h | 62 +++

Re: [PATCH v2 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

Hi Ard, On Tue, Feb 13, 2018 at 11:34:36AM +, Ard Biesheuvel wrote: > Hi Eric, > > On 12 February 2018 at 23:52, Eric Biggers <ebigg...@google.com> wrote: > > Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on > > 128-byte chunks at a time,

[PATCH v2 0/5] crypto: Speck support

: - Use the word order recommended by the Speck authors. All test vectors were updated. Eric Biggers (5): crypto: add support for the Speck block cipher crypto: speck - export common helpers crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS crypto: speck - add test

[PATCH v2 1/5] crypto: add support for the Speck block cipher

in a correspondence with them. The test vectors are taken from the original paper but were mapped to byte arrays using the recommended byte and word orders. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/Kconfig | 14 +++ crypto/Makefile | 1 + crypto/speck.c

[PATCH v2 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

possible users should use Speck128-XTS, but even that may be too slow on some processors; Speck64-XTS can be faster. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/arm/crypto/Kconfig | 6 + arch/arm/crypto/Makefile | 2 + arch/arm/crypto/speck-neon-core.S

[PATCH v2 4/5] crypto: speck - add test vectors for Speck128-XTS

Add test vectors for Speck128-XTS, generated in userspace using C code. The inputs were borrowed from the AES-XTS test vectors. Both xts(speck128-generic) and xts-speck128-neon pass these tests. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 9 + crypto/tes

[PATCH v2 5/5] crypto: speck - add test vectors for Speck64-XTS

block size. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 9 + crypto/testmgr.h | 671 +++ 2 files changed, 680 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index e011a347d51b..9f82e7bc9c56

[PATCH v2 2/5] crypto: speck - export common helpers

le, while the generic encryption and decryption functions are needed as fallbacks and for the XTS tweak encryption. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/speck.c | 90 +++--- include/cryp

Re: [PATCH 0/5] crypto: Speck support

Hi Jeff, On Mon, Feb 12, 2018 at 02:57:06PM -0500, Jeffrey Walton wrote: > On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers <ebigg...@google.com> wrote: > > Hi all, > > > > On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote: > >> > Hi Jeffrey,

Re: [PATCH 0/5] crypto: Speck support

Hi all, On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote: > > Hi Jeffrey, > > > > I see you wrote the SPECK implementation in Crypto++, and you are treating > > the > > words as big endian. > > > > Do you have a reference for this being the "correct" order? Unfortunately > > the

Re: BUG: unable to handle kernel NULL pointer dereference in sha512_mb_mgr_get_comp_job_avx2

On Sun, Dec 03, 2017 at 12:31:01PM -0800, syzbot wrote: > syzkaller has found reproducer for the following crash on > 4131d5166185d0d75b5f1d4bf362a9e0bac05598 > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached.

Re: [PATCH 0/5] crypto: Speck support

On Wed, Feb 07, 2018 at 08:47:05PM -0500, Jeffrey Walton wrote: > On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers <ebigg...@google.com> wrote: > > Hello, > > > > This series adds Speck support to the crypto API, including the Speck128 > > and Speck64 variants. Sp

[PATCH 4/5] crypto: speck - add test vectors for Speck128-XTS

Add test vectors for Speck128-XTS, generated in userspace using C code. The inputs were borrowed from the AES-XTS test vectors. Both xts(speck128-generic) and xts-speck128-neon pass these tests. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 9 + crypto/tes

[PATCH 5/5] crypto: speck - add test vectors for Speck64-XTS

block size. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/testmgr.c | 9 + crypto/testmgr.h | 671 +++ 2 files changed, 680 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 6583c11f0f0b..4b5fce3910f8

[PATCH 2/5] crypto: speck - export common helpers

le, while the generic encryption and decryption functions are needed as fallbacks and for the XTS tweak encryption. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/speck.c | 90 +++--- include/cryp

[PATCH 1/5] crypto: add support for the Speck block cipher

construction and would be more complicated and difficult to implement efficiently in comparison to Speck-XTS. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/Kconfig | 14 +++ crypto/Makefile | 1 + crypto/speck.c | 294 +++

[PATCH 0/5] crypto: Speck support

faster than the generic implementation and therefore is the implementation that would primarily be used in practice on the devices we are targeting. There is no AArch64 implementation added, since such CPUs are likely to have the Cryptography Extensions, allowing the use of AES. Eric Biggers (5

[PATCH 3/9] PKCS#7: fix direct verification of SignerInfo signature

From: Eric Biggers <ebigg...@google.com> If none of the certificates in a SignerInfo's certificate chain match a trusted key, nor is the last certificate signed by a trusted key, then pkcs7_validate_trust_one() tries to check whether the SignerInfo's signature was made directly by a trust

[PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported

From: Eric Biggers <ebigg...@google.com> The X.509 parser mishandles the case where the certificate's signature's hash algorithm is not available in the crypto API. In this case, x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; this part seems to be intention

[PATCH 5/9] X.509: fix NULL dereference when restricting key with unsupported_sig

From: Eric Biggers <ebigg...@google.com> The asymmetric key type allows an X.509 certificate to be added even if its signature's hash algorithm is not available in the crypto API. In that case 'payload.data[asym_auth]' will be NULL. But the key restriction code failed to check for thi

[PATCH 0/9] PKCS#7 / X.509 fixes and cleanups

From: Eric Biggers <ebigg...@google.com> Hi David, here is another set of fixes and cleanups for the PKCS#7 and X.509 code: Patches 1-5 fix the BUG_ON() in public_key_verify_signature() reported by Paolo Valente as well as several other bugs I found. Notably both the PKCS#7 certificate

[PATCH 8/9] X.509: remove dead code that set ->unsupported_sig

From: Eric Biggers <ebigg...@google.com> The X.509 parser is guaranteed to set cert->sig->pkey_algo and cert->sig->hash_algo, since x509_note_pkey_algo() is a mandatory action in the X.509 ASN.1 grammar, and it returns an error code if an unrecognized AlgorithmIdentifier is

[PATCH 7/9] X.509: remove never-set ->unsupported_key flag

From: Eric Biggers <ebigg...@google.com> The X.509 parser is guaranteed to set cert->pub->pkey_algo, since x509_extract_key_data() is a mandatory action in the X.509 ASN.1 grammar, and it returns an error code if an unrecognized AlgorithmIdentifier is given rather than leaving t

[PATCH 9/9] X.509: self_signed implies !unsupported_sig

From: Eric Biggers <ebigg...@google.com> The self_signed flag on a certificate implies we verified its signature. Hence, the signature cannot have been unsupported. Remove the dead code that resulted from this oversight. Signed-off-by: Eric Biggers <ebigg...@google.com>

[PATCH 1/9] PKCS#7: fix certificate chain verification

From: Eric Biggers <ebigg...@google.com> When pkcs7_verify_sig_chain() is building the certificate chain for a SignerInfo using the certificates in the PKCS#7 message, it is passing the wrong arguments to public_key_verify_signature(). Consequently, when the next certificate is su

[PATCH 6/9] PKCS#7: remove unnecessary check for NULL sinfo->sig->hash_algo

From: Eric Biggers <ebigg...@google.com> The PKCS#7 parser is guaranteed to set ->sig->hash_algo for every SignerInfo, since pkcs7_sig_note_digest_algo() is a mandatory action in the PKCS#7 ASN.1 grammar, and it returns an error code if an unrecognized DigestAlgorithmIdentifier is

[PATCH 2/9] PKCS#7: fix certificate blacklisting

From: Eric Biggers <ebigg...@google.com> If there is a blacklisted certificate in a SignerInfo's certificate chain, then pkcs7_verify_sig_chain() sets sinfo->blacklisted and returns 0. But, pkcs7_verify() fails to handle this case appropriately, as it actually continues on to

Re: BUG: unable to handle kernel NULL pointer dereference in __crypto_register_alg

On Sat, Dec 23, 2017 at 11:54:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: > On Fri, Feb 2, 2018 at 2:48 PM, syzbot > wrote: > > Hello, > > > > syzbot hit the following crash on upstream commit > > 7109a04eae81c41ed529da9f3c48c3655ccea741 (Thu Feb 1

Re: BUG: unable to handle kernel NULL pointer dereference in crypto_destroy_tfm

On Sat, Dec 23, 2017 at 01:58:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: BUG: unable to handle kernel paging request in aead_accept_parent_nokey

On Sun, Dec 17, 2017 at 09:51:01PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 41d8c16909ebda40f7b4982a7f5e2ad102705ade > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: BUG: unable to handle kernel NULL pointer dereference in af_alg_alloc_tsgl

On Tue, Dec 19, 2017 at 01:03:00PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: BUG: unable to handle kernel paging request in hmac_init_tfm

On Mon, Dec 18, 2017 at 11:36:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: Subject: [PATCH] crypto: add zbewalgo compression algorithm for zram

Hi Benjamin, On Tue, Jan 30, 2018 at 04:08:57PM +0100, Benjamin Warnke wrote: > Currently ZRAM uses the compression-algorithms from the crypto-api. > None of the current compression-algorithms in the crypto-api is designed > to compress 4KiB chunks of data efficiently. > This patch adds a new

Re: [PATCH] crypto: sha1-mb - remove HASH_FIRST flag

On Thu, Jan 25, 2018 at 01:58:38PM -0800, Tim Chen wrote: > On 01/24/2018 07:10 PM, Eric Biggers wrote: > > From: Eric Biggers <ebigg...@google.com> > > > > The HASH_FIRST flag is never set. Remove it. > > > > Signed-off-by: Eric Biggers <ebigg...@goo

[PATCH] crypto: sha512-mb - remove HASH_FIRST flag

From: Eric Biggers <ebigg...@google.com> The HASH_FIRST flag is never set. Remove it. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/sha512-mb/sha512_mb.c | 30 +++--- arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 8 +++- 2 file

[PATCH] crypto: sha1-mb - remove HASH_FIRST flag

From: Eric Biggers <ebigg...@google.com> The HASH_FIRST flag is never set. Remove it. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/sha1-mb/sha1_mb.c | 28 +++- arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 8 +++- 2 file

[PATCH] crypto: mcryptd - remove pointless wrapper functions

From: Eric Biggers <ebigg...@google.com> There is no need for ahash_mcryptd_{update,final,finup,digest}(); we should just call crypto_ahash_*() directly. Signed-off-by: Eric Biggers <ebigg...@google.com> --- crypto/mcryptd.c | 34 -- in

[PATCH] crypto: sha256-mb - remove HASH_FIRST flag

From: Eric Biggers <ebigg...@google.com> The HASH_FIRST flag is never set. Remove it. Signed-off-by: Eric Biggers <ebigg...@google.com> --- arch/x86/crypto/sha256-mb/sha256_mb.c | 27 +++ arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 8 +++- 2 file

[PATCH] crypto: sha512-mb - initialize pending lengths correctly

From: Eric Biggers <ebigg...@google.com> The SHA-512 multibuffer code keeps track of the number of blocks pending in each lane. The minimum of these values is used to identify the next lane that will be completed. Unused lanes are set to a large number (0x) so that they don't

Re: kernel failure while loading X.509 certificate

On Thu, Jan 18, 2018 at 11:07:50AM +0100, Paolo Valente wrote: > > > > Il giorno 17 gen 2018, alle ore 12:08, David Howells > > ha scritto: > > > > If this happened during boot, it could be that you have an X.509 cert for > > which the digest algorithm isn't built into

Re: general protection fault in __crypto_alg_lookup

On Tue, Dec 19, 2017 at 11:49:02PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: BUG: unable to handle kernel NULL pointer dereference in crypto_alg_tested

On Fri, Dec 22, 2017 at 11:33:02PM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 6084b576dca2e898f5c101baef151f7bfdbb606d > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

<    1   2   3   4   5   >