On Mon, Oct 14, 2019 at 04:47:27AM +, Jamie Heilman wrote:
> Eric Biggers wrote:
> > > I built a patched 5.3.6 with none of the crypto bits modularized
> > > and you can find that dmesg and config at:
> > >
> > > http://audible.transient.net/~j
On Mon, Oct 14, 2019 at 10:45:22AM +0200, Ard Biesheuvel wrote:
> Hi Eric,
>
> On Sat, 12 Oct 2019 at 04:32, Eric Biggers wrote:
> >
> > From: Eric Biggers
> >
> > Convert the glue code for the PowerPC SPE implementations of AES-ECB,
> > AES-CBC, A
From: Eric Biggers
The PowerPC SPE implementations of AES modes only disable preemption
during the actual encryption/decryption, not during the scatterwalk
functions. It's therefore unnecessary to request an atomic scatterwalk.
So don't do so.
Signed-off-by: Eric Biggers
---
ar
From: Eric Biggers
Set the ivsize for the "ecb-ppc-spe" algorithm to 0, since ECB mode
doesn't take an IV.
This fixes a failure in the extra crypto self-tests:
alg: skcipher: ivsize for ecb-ppc-spe (16) doesn't match generic impl
(0)
Signed-off-by: Eric Bigger
From: Eric Biggers
Convert the glue code for the PowerPC SPE implementations of AES-ECB,
AES-CBC, AES-CTR, and AES-XTS from the deprecated "blkcipher" API to the
"skcipher" API. This is needed in order for the blkcipher API to be
removed.
Tested with:
export ARCH=p
plit fixes into separate patches.
- Made ppc_aes_setkey_skcipher() call ppc_aes_setkey(), rather than
creating a separate expand_key() function. This keeps the code
shorter.
Eric Biggers (3):
crypto: powerpc - don't unnecessarily use atomic scatterwalk
crypto: powerpc - don't set ivsi
On Tue, Oct 15, 2019 at 01:11:38AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 11, 2019 at 09:38:47PM -0700, Eric Biggers wrote:
> > This series converts the glue code for the SPARC64 crypto opcodes
> > implementations of AES, Camellia, DES, and 3DES modes from the
> > depre
On Tue, Oct 15, 2019 at 01:31:39PM +0200, Harald Freudenberger wrote:
> On 12.10.19 22:18, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Convert the glue code for the S390 CPACF protected key implementations
> > of AES-ECB, AES-CBC, AES-XTS, and AES-CTR from th
On Wed, Oct 09, 2019 at 04:38:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Instead of open-coding the calculations for ESSIV handling, use an ESSIV
> skcipher which does all of this under the hood. ESSIV was added to the
> crypto API in v5.4.
>
> This is base
On Thu, Oct 17, 2019 at 09:08:59PM +0200, Ard Biesheuvel wrote:
> +static inline void chacha_crypt(u32 *state, u8 *dst, const u8 *src,
> + unsigned int bytes, int nrounds)
> +{
> + if (IS_ENABLED(CONFIG_CRYPTO_ARCH_HAVE_LIB_CHACHA))
> + chacha_crypt_arch(
On Thu, Oct 17, 2019 at 09:09:01PM +0200, Ard Biesheuvel wrote:
> +void hchacha_block_arch(const u32 *state, u32 *stream, int nrounds)
> +{
> + state = PTR_ALIGN(state, CHACHA_STATE_ALIGN);
> +
> + if (!static_branch_likely(&chacha_use_simd) || !crypto_simd_usable()) {
> + hchac
On Thu, Oct 17, 2019 at 09:08:59PM +0200, Ard Biesheuvel wrote:
> diff --git a/lib/crypto/libchacha.c b/lib/crypto/libchacha.c
> new file mode 100644
> index ..7b4b97811f71
> --- /dev/null
> +++ b/lib/crypto/libchacha.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
On Thu, Oct 17, 2019 at 09:09:03PM +0200, Ard Biesheuvel wrote:
> +void hchacha_block_arch(const u32 *state, u32 *stream, int nrounds)
> +{
> + if (!static_branch_likely(&have_neon) || !crypto_simd_usable()) {
> + hchacha_block_generic(state, stream, nrounds);
> + } else {
> +
On Thu, Oct 17, 2019 at 09:09:05PM +0200, Ard Biesheuvel wrote:
> Instead of falling back to the generic ChaCha skcipher driver for
> non-SIMD cases, use a fast scalar implementation for ARM authored
> by Eric Biggers. This removes the module dependency on chacha-generic
> altogether
On Thu, Oct 17, 2019 at 09:09:21PM +0200, Ard Biesheuvel wrote:
> Wire up our newly added Blake2s implementation via the shash API.
>
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/Kconfig| 4 +
> crypto/Makefile | 1 +
> crypto/blake2s-generic.c
On Thu, Oct 17, 2019 at 09:09:01PM +0200, Ard Biesheuvel wrote:
> +void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src, unsigned int
> bytes,
> +int nrounds)
> +{
> + state = PTR_ALIGN(state, CHACHA_STATE_ALIGN);
> +
> + if (!static_branch_likely(&chacha_use_simd)
On Thu, Oct 17, 2019 at 09:09:19PM +0200, Ard Biesheuvel wrote:
> diff --git a/lib/crypto/blake2s-selftest.c b/lib/crypto/blake2s-selftest.c
> new file mode 100644
> index ..7ba00fcc6b60
> --- /dev/null
> +++ b/lib/crypto/blake2s-selftest.c
> @@ -0,0 +1,2093 @@
> +// SPDX-License-Identi
On Thu, Oct 17, 2019 at 09:09:22PM +0200, Ard Biesheuvel wrote:
> From: "Jason A. Donenfeld"
>
> These implementations from Samuel Neves support AVX and AVX-512VL.
> Originally this used AVX-512F, but Skylake thermal throttling made
> AVX-512VL more attractive and possible to do with negligable d
From: Eric Biggers
The SHA-256 / SHA-224 library functions can't fail, so remove the
useless return value.
Also long as the declarations are being changed anyway, also fix some
parameter names in the declarations to match the definitions.
Signed-off-by: Eric Biggers
---
c
On Fri, May 01, 2020 at 02:28:12PM +0200, Christophe Leroy wrote:
> > -extern int sha256_update(struct sha256_state *sctx, const u8 *input,
> > -unsigned int length);
> > -extern int sha256_final(struct sha256_state *sctx, u8 *hash);
> > +extern void sha256_update(struct sha256_
From: Eric Biggers
The SHA-256 / SHA-224 library functions can't fail, so remove the
useless return value.
Also long as the declarations are being changed anyway, also fix some
parameter names in the declarations to match the definitions.
Signed-off-by: Eric Biggers
---
v2: r
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Cheng-Yi Chiang
Cc: Enric Balletbo i Serra
Cc: Guenter Roeck
Sig
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Signed-off-by: Eric Biggers
---
fs/crypto/fname.c | 7 +--
fs/cry
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: linux-...@lists.infradead.org
Signed-off-by: Eric Biggers
---
fs/ub
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Eric Biggers
---
net/s
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Jesper Nilsson
Cc: Lars Persson
Signed-off-by: Eric Biggers
--
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: ecryp...@vger.kernel.org
Signed-off-by: Eric Biggers
---
fs/ecryptf
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: keyri...@vger.kernel.org
Signed-off-by: Eric Biggers
---
sec
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Signed-off-by: Eric Biggers
---
drivers/crypto/omap-s
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: linux-...@vger.kernel.org
Signed-off-by: Eric Biggers
---
fs/nfsd/nfs
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Signed-off-by: Eric Biggers
---
crypto/essiv.c | 4 +---
1 file
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Krzysztof Kozlowski
Cc: Vladimir Zapolskiy
Cc: Kamil Konieczny
Sig
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Signed-off-by: Eric Biggers
---
drivers/crypto/mediatek/mtk-sha.c | 7
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Zaibo Xu
Signed-off-by: Eric Biggers
---
drivers/crypto/hisi
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Signed-off-by: Eric Biggers
---
drivers/crypto/n2_core.c | 7 ++---
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: linux-blueto...@vger.kernel.org
Signed-off-by: Eric Biggers
---
net
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Tom Lendacky
Signed-off-by: Eric Biggers
---
drivers/crypto/ccp/
But taking just the "crypto:" ones and then me trying to get the
rest merged later via subsystem trees is also an option.
Eric Biggers (20):
crypto: hash - introduce crypto_shash_tfm_digest()
crypto: arm64/aes-glue - use crypto_shash_tfm_digest()
crypto: essiv - use crypto_shash_tfm_dige
From: Eric Biggers
Currently the simplest use of the shash API is to use
crypto_shash_digest() to digest a whole buffer. However, this still
requires allocating a hash descriptor (struct shash_desc). Many users
don't really want to preallocate one and instead just use a one-off
descript
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Robert Baldyga
Cc: Krzysztof Opasiak
Signed-off-by: Eric Biggers
--
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Gilad Ben-Yossef
Signed-off-by: Eric Biggers
---
drivers/cr
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Signed-off-by: Eric Biggers
---
arch/arm64/crypto/aes-glue.c | 4 +-
From: Eric Biggers
crypto_shash_descsize() returns the size of the shash_desc context
needed to compute the hash, not the size of the hash itself.
crypto_shash_digestsize() would be correct, or alternatively using
c->hash_len and c->hmac_desc_len which already store the correct value
From: Eric Biggers
The return value of xxh64_update() is pointless and confusing, since an
error is only returned for input==NULL. But the callers must ignore
this error because they might pass input=NULL, length=0.
Likewise for xxh32_update().
Just make these functions return void.
Cc
On Sat, May 02, 2020 at 11:01:35AM +0300, Nikolay Borisov wrote:
> > +void xxh32_update(struct xxh32_state *state, const void *input,
> > + const size_t len)
> > {
> > const uint8_t *p = (const uint8_t *)input;
> > const uint8_t *const b_end = p + len;
> >
> > - if (input =
From: Eric Biggers
The library implementation of the SHA-1 compression function is
confusingly called just "sha_transform()". Alongside it are some "SHA_"
constants and "sha_init()". Presumably these are left over from a time
when SHA just meant SHA-1. But now
From: Eric Biggers
sounds very generic and important, like it's the
header to include if you're doing cryptographic hashing in the kernel.
But actually it only includes the library implementation of the SHA-1
compression function (not even the full SHA-1). This should basically
nev
From: Eric Biggers
Prefix the PowerPC SHA-1 functions with "powerpc_sha1_" rather than
"sha1_". This allows us to rename the library function sha_init() to
sha1_init() without causing a naming collision.
Cc: linuxppc-...@lists.ozlabs.org
Cc: Benjamin Herrenschmidt
Cc:
From: Eric Biggers
Prefix the s390 SHA-1 functions with "s390_sha1_" rather than "sha1_".
This allows us to rename the library function sha_init() to sha1_init()
without causing a naming collision.
Cc: linux-s...@vger.kernel.org
Signed-off-by: Eric Biggers
---
arch/s39
From: Eric Biggers
sounds very generic and important, like it's the
header to include if you're doing cryptographic hashing in the kernel.
But actually it only includes the library implementation of the SHA-1
compression function (not even the full SHA-1). This should basically
nev
From: Eric Biggers
In preparation for naming the SHA-1 stuff in
properly and moving it to a more appropriate header, fix the HMAC-SHA256
code in mptcp_crypto_hmac_sha() to use SHA256_BLOCK_SIZE instead of
"SHA_MESSAGE_BYTES" which is actually the SHA-1 block size.
(Fortunately these a
.
This patch series applies to cryptodev/master.
Eric Biggers (7):
mptcp: use SHA256_BLOCK_SIZE, not SHA_MESSAGE_BYTES
crypto: powerpc/sha1 - remove unused temporary workspace
crypto: powerpc/sha1 - prefix the "sha1_" functions
crypto: s390/sha1 - prefix the "sha1_" fu
From: Eric Biggers
The PowerPC implementation of SHA-1 doesn't actually use the 16-word
temporary array that's passed to the assembly code. This was probably
meant to correspond to the 'W' array that lib/sha1.c uses. However, in
sha1-powerpc-asm.S these values are actually
From: Eric Biggers
The AES library code (which originally came from crypto/aes_ti.c) is
supposed to be constant-time, to the extent possible for a C
implementation. But the hardening measure of disabling interrupts while
the S-box is loaded into cache was not included in the library version;
it
On Sat, May 02, 2020 at 03:05:46PM -0600, Jason A. Donenfeld wrote:
> Thanks for this series. I like the general idea. I think it might make
> sense, though, to separate things out into sha1.h and sha256.h. That
> will be nice preparation work for when we eventually move obsolete
> primitives into
On Tue, May 12, 2020 at 05:22:05PM +0100, Mark Brown wrote:
> On Tue, May 12, 2020 at 02:49:49PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the sound-asoc tree got a conflict in:
> >
> > sound/soc/codecs/cros_ec_codec.c
> >
> > between commit:
> >
> > 85f
On Tue, May 12, 2020 at 06:08:01PM +0100, Mark Brown wrote:
> On Tue, May 12, 2020 at 09:36:32AM -0700, Eric Biggers wrote:
> > On Tue, May 12, 2020 at 05:22:05PM +0100, Mark Brown wrote:
>
> > > > from the crypto tree and commit:
>
> > > > a1304
On Thu, May 14, 2020 at 02:54:56PM -0400, Sasha Levin wrote:
> From: Eric Biggers
>
> [ Upstream commit 732e540953477083082e999ff553622c59cffd5f ]
>
> Simplify the error handling in the XTS template's ->create() function by
> taking advantage of crypto_drop_skcipher()
On Fri, May 01, 2020 at 11:34:23PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The return value of xxh64_update() is pointless and confusing, since an
> error is only returned for input==NULL. But the callers must ignore
> this error because they might pass input
On Mon, May 04, 2020 at 09:16:44AM +0200, Sascha Hauer wrote:
> On Fri, May 01, 2020 at 10:59:45PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > crypto_shash_descsize() returns the size of the shash_desc context
> > needed to compute the hash, not
From: Eric Biggers
The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
an encryption format which uses one key per policy and permits the
moving of encrypted file contents (as f2fs's garbage
On Thu, May 14, 2020 at 08:55:30PM -0400, Sasha Levin wrote:
> On Thu, May 14, 2020 at 12:08:43PM -0700, Eric Biggers wrote:
> > On Thu, May 14, 2020 at 02:54:56PM -0400, Sasha Levin wrote:
> > > From: Eric Biggers
> > >
> > > [ Upstream commit 732e
On Tue, May 19, 2020 at 07:13:21AM -0400, Theodore Y. Ts'o wrote:
> On Fri, May 15, 2020 at 01:41:41PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
> > bits), unlike UFS's
On Fri, May 15, 2020 at 01:41:41PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
> bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
> an encryption format which uses on
On Thu, May 28, 2020 at 07:00:51PM +0200, sbuisson@gmail.com wrote:
> From: Sebastien Buisson
>
> Add adler32 to CryptoAPI so that it can be used with the normal kernel
> API, and potentially accelerated if architecture-specific
> optimizations are available.
>
> Signed-off-by: Sebastien Bui
On Tue, Jun 02, 2020 at 03:59:40PM +, Sebastien Buisson wrote:
>
> > Le 1 juin 2020 à 09:13, Eric Biggers a écrit :
> >
> > On Thu, May 28, 2020 at 07:00:51PM +0200, sbuisson@gmail.com wrote:
> >> From: Sebastien Buisson
> >>
> >> Add
Probably a bug in crypto/drbg.c. Stephan, can you take a look?
On Tue, Jun 02, 2020 at 08:41:21PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:19409891 Merge tag 'pnp-5.8-rc1' of git://git.kernel.org/p..
> git tree: upstream
> console output:
On Fri, Apr 24, 2020 at 01:40:46PM +, Corentin Labbe wrote:
> As comment of the v2, Herbert said: "The SEQIV select from CTR is historical
> and no longer necessary."
>
> So let's get rid of it.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
From: Eric Biggers
When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST
is sent to crypto_chain. cryptomgr_schedule_probe() handles this by
starting a thread to instantiate the template, then waiting for this
thread to complete via crypto_larval::completion.
This can
From: Eric Biggers
Since CRYPTO_CTR no longer selects CRYPTO_SEQIV, it should be selected
by INET_ESP and INET6_ESP -- similar to CRYPTO_ECHAINIV.
Fixes: f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV")
Cc: Corentin Labbe
Cc: Greg Kroah-Hartman
Cc: Herbert Xu
Cc: Steffe
On Thu, Jun 04, 2020 at 11:52:53AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST
> is sent to crypto_chain. cryptomgr_schedule_probe() handles this by
> starting a thread to instantiate the template, t
+Cc linux-crypto. crypto_free_shash() is being called in atomic context;
perhaps that should be allowed? kfree() can be called in atomic context.
On Thu, Jun 04, 2020 at 05:33:19PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:39884604 mptcp: fix NU
On Thu, Jun 04, 2020 at 08:41:00AM +0200, Stephan Müller wrote:
> The Jitter RNG is unconditionally allocated as a seed source follwoing
> the patch 97f2650e5040. Thus, the instance must always be deallocated.
>
> Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com
> Fixes: 97f2650e
On Fri, Jun 05, 2020 at 10:29:56AM +1000, Herbert Xu wrote:
> On Fri, Jun 05, 2020 at 10:28:58AM +1000, Herbert Xu wrote:
> >
> > Hmm, the selection list doesn't include CTR so just adding SEQIV
> > per se makes no sense. I'm not certain that we really want to
> > include every algorithm under the
On Thu, Jun 04, 2020 at 04:33:24PM +1000, Herbert Xu wrote:
> +static void crc_t10dif_rehash(struct work_struct *work)
> +{
> + struct crypto_shash *new, *old;
> +
> mutex_lock(&crc_t10dif_mutex);
> old = rcu_dereference_protected(crct10dif_tfm,
>
On Fri, Jun 05, 2020 at 07:58:15AM +0200, Stephan Mueller wrote:
> Am Freitag, 5. Juni 2020, 02:43:36 CEST schrieb Eric Biggers:
>
> Hi Eric,
>
> > On Thu, Jun 04, 2020 at 08:41:00AM +0200, Stephan Müller wrote:
> > > The Jitter RNG is unconditionally allocated
On Fri, Jun 05, 2020 at 11:26:20PM +0800, Zhangfei Gao wrote:
>
>
> On 2020/6/5 下午8:17, Herbert Xu wrote:
> > On Fri, Jun 05, 2020 at 05:34:32PM +0800, Zhangfei Gao wrote:
> > > Will add a check after the copy.
> > >
> > > strlcpy(interface.name, pdev->driver->name,
> > > sizeof(interf
On Fri, Jun 05, 2020 at 08:52:57AM +0200, Stephan Mueller wrote:
> Am Freitag, 5. Juni 2020, 08:16:46 CEST schrieb Eric Biggers:
>
> Hi Eric,
>
> > On Fri, Jun 05, 2020 at 07:58:15AM +0200, Stephan Mueller wrote:
> > > Am Freitag, 5. Juni 2020, 02:43:36 CEST schrieb Er
From: Eric Biggers
CRYPTO_CTR no longer selects CRYPTO_SEQIV, which breaks IPsec for users
who need any of the algorithms that use seqiv. These users now would
need to explicitly enable CRYPTO_SEQIV.
There doesn't seem to be a clear rule on what algorithms the IPsec
options (INET_ES
On Fri, Jun 05, 2020 at 10:39:31AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> CRYPTO_CTR no longer selects CRYPTO_SEQIV, which breaks IPsec for users
> who need any of the algorithms that use seqiv. These users now would
> need to explicitly enable CRYPTO_SEQIV.
>
&g
On Fri, Jun 05, 2020 at 04:59:18PM +1000, Herbert Xu wrote:
> The crypto notify call occurs with a read mutex held so you must
> not do any substantial work directly. In particular, you cannot
> call crypto_alloc_* as they may trigger further notifications
> which may dead-lock in the presence of
On Fri, Jun 05, 2020 at 11:22:37AM -0700, Eric Biggers wrote:
>
> Wouldn't it be better to have crct10dif_fallback enabled by default, and then
> disable it once the tfm is allocated?
>
> That would make the checks for a NULL tfm in crc_t10dif_transform_show() and
On Sat, Jun 06, 2020 at 04:25:22AM +1000, Herbert Xu wrote:
> > That would make the checks for a NULL tfm in crc_t10dif_transform_show() and
> > crc_t10dif_notify() unnecessary. Also, it would make it so that
> > crc_t10dif_update() no longer crashes if called before module_init().
>
> crc_t10dif
From: Eric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MU
...@kernel.org/T/#u
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm selections
esp: select CRYPTO_SEQIV
esp, ah: modernize the crypto algorithm selections
net/ipv4/Kconfig | 37 +
net/ipv6/Kconfig | 37 +
net/xfrm
From: Eric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST&
From: Eric Biggers
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu
This series makes some more improvements to lib/crc-t10dif.c, as discussed at
https://lkml.kernel.org/linux-crypto/20200604063324.ga28...@gondor.apana.org.au/T/#u
This applies on top of Herbert's
"[v2 PATCH] crc-t10dif: Fix potential crypto notify dead-lock".
Eric Biggers (2):
From: Eric Biggers
- Correctly compare the algorithm name in crc_t10dif_notify().
- Use proper NOTIFY_* status codes instead of 0.
- Consistently use CRC_T10DIF_STRING instead of "crct10dif" directly.
- Use a proper type for the shash_desc context.
- Use crypto_shash_driver_name()
From: Eric Biggers
Currently the crc-t10dif module starts out with the fallback disabled
and crct10dif_tfm == NULL. crc_t10dif_mod_init() tries to allocate
crct10dif_tfm, and if it fails it enables the fallback.
This is backwards because it means that any call to crc_t10dif() prior
to
Fixes: 11dcb1037f40 ("crc-t10dif: Allow current transform to be...")
> Fixes: b76377543b73 ("crc-t10dif: Pick better transform if one...")
> Signed-off-by: Herbert Xu
Reviewed-by: Eric Biggers
- Eric
On Sun, Jun 07, 2020 at 01:03:45PM +, David Laight wrote:
> From: Herbert Xu
> > Sent: 05 June 2020 13:17
> ...
> > Better yet use strscpy which will even return an error for you.
>
> It really ought to return the buffer length on truncation.
> Then you can loop:
> while(...)
>
On Wed, Jun 10, 2020 at 11:03:55AM +0200, Tobias Brunner wrote:
> Hi Eric,
>
> > + Note that RFC 8221 considers AH itself to be "NOT RECOMMENDED". It is
> > + better to use ESP only, using an AEAD cipher such as AES-GCM.
>
> What's NOT RECOMMENDED according to the RFC is the combination
From: Eric Biggers
Commit f23efcbcc523 ("crypto: ctr - no longer needs CRYPTO_SEQIV") made
CRYPTO_CTR stop selecting CRYPTO_SEQIV. This breaks IPsec for most
users since GCM and several other encryption algorithms require "seqiv"
-- and RFC 8221 lists AES-GCM as "MU
...@kernel.org/T/#u
Changed v3 => v4:
- Don't say that AH is "NOT RECOMMENDED" by RFC 8221.
- Updated commit messages (added Acked-by tags, fixed a bad Fixes tag,
added some more explanation to patch 3).
Eric Biggers (3):
esp, ah: consolidate the crypto algorithm select
From: Eric Biggers
The crypto algorithms selected by the ESP and AH kconfig options are
out-of-date with the guidance of RFC 8221, which lists the legacy
algorithms MD5 and DES as "MUST NOT" be implemented, and some more
modern algorithms like AES-GCM and HMAC-SHA256 as "MUST&
From: Eric Biggers
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu
On Mon, Jun 15, 2020 at 10:14:45AM +0300, Tero Kristo wrote:
> Hi,
>
> This is basically just a rebase of v2 to 5.8-rc1, and application of
> Rob's Ack on the dt-binding patch. No other changes.
>
> Only driver side + DT binding should be applied via the crypto tree, DTS
> patches should be queue
On Mon, Jun 15, 2020 at 09:50:50AM +0200, Ard Biesheuvel wrote:
> On Mon, 15 Jun 2020 at 09:30, Herbert Xu wrote:
> >
> > On Fri, Jun 12, 2020 at 06:10:57PM +0200, Ard Biesheuvel wrote:
> > >
> > > First of all, the default fcsize for all existing XTS implementations
> > > should be -1 as well, gi
From: Eric Biggers
Instead of duplicating the algorithm selections between INET_AH and
INET6_AH and between INET_ESP and INET6_ESP, create new tristates
XFRM_AH and XFRM_ESP that do the algorithm selections, and make these be
selected by the corresponding INET* options.
Suggested-by: Herbert Xu
401 - 500 of 1650 matches
Mail list logo
