linux-next specific files for 20190729
0d8b3265d9a6376b416b3ba86f758a5c6a85a6df
Compiler: m68k-linux-gcc (GCC) 4.6.3 / GNU ld (GNU Binutils) 2.22
Possible errors
---
crypto/aegis128-core.c:19:22: fatal error: asm/simd.h: No such file or directory
make[2]: *** [scripts
The generic aegis128 driver has been updated to support using SIMD
intrinsics to implement the core AES based transform, and this has
been wired up for ARM and arm64, which both provide a simd.h header.
As it turns out, most architectures don't provide this header, even
though a version of it exis
Hi Ard,
On Mon, Jul 29, 2019 at 9:44 AM Ard Biesheuvel
wrote:
> The generic aegis128 driver has been updated to support using SIMD
> intrinsics to implement the core AES based transform, and this has
> been wired up for ARM and arm64, which both provide a simd.h header.
>
> As it turns out, most
On Mon, 29 Jul 2019 at 10:55, Geert Uytterhoeven wrote:
>
> Hi Ard,
>
> On Mon, Jul 29, 2019 at 9:44 AM Ard Biesheuvel
> wrote:
> > The generic aegis128 driver has been updated to support using SIMD
> > intrinsics to implement the core AES based transform, and this has
> > been wired up for ARM a
Hi Ard,
On Mon, Jul 29, 2019 at 10:02 AM Ard Biesheuvel
wrote:
> On Mon, 29 Jul 2019 at 10:55, Geert Uytterhoeven wrote:
> > On Mon, Jul 29, 2019 at 9:44 AM Ard Biesheuvel
> > wrote:
> > > The generic aegis128 driver has been updated to support using SIMD
> > > intrinsics to implement the core
Hi Eric,
Thanks for your feedback!
> -Original Message-
> From: Eric Biggers
> Sent: Sunday, July 28, 2019 7:31 PM
> To: Pascal van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au;
> da...@davemloft.net; Pascal Van Leeuwen
>
> Subject: Re: [PATCH] crypto: testm
Ard Biesheuvel wrote:
> The generic aegis128 driver has been updated to support using SIMD
> intrinsics to implement the core AES based transform, and this has
> been wired up for ARM and arm64, which both provide a simd.h header.
>
> As it turns out, most architectures don't provide this header,
On Mon, 29 Jul 2019 at 12:12, Herbert Xu wrote:
>
> Ard Biesheuvel wrote:
> > The generic aegis128 driver has been updated to support using SIMD
> > intrinsics to implement the core AES based transform, and this has
> > been wired up for ARM and arm64, which both provide a simd.h header.
> >
> >
On Mon, Jul 29, 2019 at 12:15:20PM +0300, Ard Biesheuvel wrote:
>
> It is simply a matter of adding simd.h to the various
> arch/<...>/include/asm/Kbuild files, but we'd have to do that for all
> architectures.
How does errno.h get added then? It doesn't appear to be in the
m68k (or arm) Kbuild fi
On Mon, 29 Jul 2019 at 12:21, Herbert Xu wrote:
>
> On Mon, Jul 29, 2019 at 12:15:20PM +0300, Ard Biesheuvel wrote:
> >
> > It is simply a matter of adding simd.h to the various
> > arch/<...>/include/asm/Kbuild files, but we'd have to do that for all
> > architectures.
>
> How does errno.h get ad
On Mon, Jul 29, 2019 at 12:32:33PM +0300, Ard Biesheuvel wrote:
>
> This seems to work
Looks good to me.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
The generic aegis128 software crypto driver recently gained support
for using SIMD intrinsics to increase performance, for which it
uncondionally #include's the header. Unfortunately,
this header does not exist on many architectures, resulting in
build failures.
Since asm-generic already has a ve
On Mon, Jul 29, 2019 at 11:55 AM Ard Biesheuvel
wrote:
>
> The generic aegis128 software crypto driver recently gained support
> for using SIMD intrinsics to increase performance, for which it
> uncondionally #include's the header. Unfortunately,
> this header does not exist on many architectures
Fix AEAD handling of authentication failures.
Gilad Ben-Yossef (2):
crypto: ccree: use the full crypt length value
crypto: ccree: use std api sg_zero_buffer
drivers/crypto/ccree/cc_aead.c | 3 ++-
drivers/crypto/ccree/cc_buffer_mgr.c | 21 -
drivers/crypto/ccree/cc
Replace internal cc_zero_sgl() with kernel API of the same function
sg_zero_buffer().
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_aead.c | 3 ++-
drivers/crypto/ccree/cc_buffer_mgr.c | 21 -
drivers/crypto/ccree/cc_buffer_mgr.h | 2 --
3 files changed,
In case of AEAD decryption verifcation error we were using the
wrong value to zero out the plaintext buffer leaving the end of
the buffer with the false plaintext.
Signed-off-by: Gilad Ben-Yossef
Fixes: ff27e85a85bb ("crypto: ccree - add AEAD support")
CC: sta...@vger.kernel.org # v4.17+
---
dri
On Mon, 29 Jul 2019 at 13:32, Arnd Bergmann wrote:
>
> On Mon, Jul 29, 2019 at 11:55 AM Ard Biesheuvel
> wrote:
> >
> > The generic aegis128 software crypto driver recently gained support
> > for using SIMD intrinsics to increase performance, for which it
> > uncondionally #include's the header.
On Mon, Jul 29, 2019 at 12:45 PM Ard Biesheuvel
wrote:
> On Mon, 29 Jul 2019 at 13:32, Arnd Bergmann wrote:
> > It looks like there are a number of these that could be handled the
> > same way. Should we do that for the asm-generic tree afterwards?
> >
>
> I guess it depends whether any dependenc
From: Gary R Hook
If there are no CCP devices on the system, ccp-crypto will not load.
Write a message to the system log clarifying the reason for the failure
of the modprobe operation
Signed-off-by: Gary R Hook
---
Changes since v1:
- Add missing signed-off-by
drivers/crypto/ccp/ccp-crypto
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> In order to be able to unify 64 and 32 bit implementations of
> wr_reg64, let's convert it to use helpers from
> first. Here are the steps of the
> transformation:
>
> 1. Inline wr_reg32 helpers:
>
> if (!caam_imx && caam_little_end) {
>
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> Following the same transformation logic as outlined in previous commit
> converting wr_reg64, convert rd_reg64 to use helpers from
> first. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> Since 32-bit of both wr_reg64 and rd_reg64 now use 64-bit IO helpers,
> these functions should no longer be necessary. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Thanks,
Horia
Hi Eric,
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of
> Pascal Van Leeuwen
> Sent: Monday, July 29, 2019 11:11 AM
> To: Eric Biggers ; Pascal van Leeuwen
>
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au;
> da...@davemloft.net
> Subjec
On Mon, Jul 29, 2019 at 09:10:38AM +, Pascal Van Leeuwen wrote:
> Hi Eric,
>
> Thanks for your feedback!
>
> > -Original Message-
> > From: Eric Biggers
> > Sent: Sunday, July 28, 2019 7:31 PM
> > To: Pascal van Leeuwen
> > Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.
On Mon, Jul 29, 2019 at 04:10:06PM +, Pascal Van Leeuwen wrote:
> Hi Eric,
>
> > -Original Message-
> > From: linux-crypto-ow...@vger.kernel.org
> > On Behalf Of
> > Pascal Van Leeuwen
> > Sent: Monday, July 29, 2019 11:11 AM
> > To: Eric Biggers ; Pascal van Leeuwen
> >
> > Cc: li
From: Wen Yang
commit 95566aa75cd6b3b404502c06f66956b5481194b3 upstream.
There is a possible double free issue in ppc4xx_trng_probe():
85: dev->trng_base = of_iomap(trng, 0);
86: of_node_put(trng); ---> released here
87: if (!dev->trng_base)
88: goto err_out;
..
On Sun, Jul 28, 2019 at 02:50:03PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:31PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Add a new fscrypt ioctl, FS_IOC_ADD_ENCRYPTION_KEY. This ioctl adds an
> > encryption key to the filesystem's fscrypt keyring ->s_maste
On Sun, Jul 28, 2019 at 03:24:17PM -0400, Theodore Y. Ts'o wrote:
> > +
> > +/*
> > + * Try to remove an fscrypt master encryption key. If other users have
> > also
> > + * added the key, we'll remove the current user's usage of the key, then
> > return
> > + * -EUSERS. Otherwise we'll continue
On Thu, Jul 25, 2019 at 05:24:59PM -0400, Daniel Jordan wrote:
> Change the calling convention for apply_workqueue_attrs to require CPU
> hotplug read exclusion.
>
> Avoids lockdep complaints about nested calls to get_online_cpus in a
> future patch where padata calls apply_workqueue_attrs when ch
On Thu, Jul 25, 2019 at 05:24:58PM -0400, Daniel Jordan wrote:
> padata will use these these interfaces in a later patch, so unconfine them.
>
> Signed-off-by: Daniel Jordan
Acked-by: Tejun Heo
Thanks.
--
tejun
Hi Ted, thanks for the review!
On Sun, Jul 28, 2019 at 11:40:32AM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:30PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > In preparation for introducing v2 encryption policies which will find
> > and derive encryption keys dif
From: Daniel Jordan
commit cf144f81a99d1a3928f90b0936accfd3f45c9a0a upstream.
Testing padata with the tcrypt module on a 5.2 kernel...
# modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3
# modprobe tcrypt mode=211 sec=1
...produces this splat:
INFO: task modprobe:10075 blocke
On Mon, Jul 29, 2019 at 12:46:45PM -0700, Eric Biggers wrote:
> > For that matter, we could just add a new ioctl which returns the file
> > system's keyring id. That way an application program won't have to
> > try to figure out what a file's underlying sb->s_id happens to be.
> > (Especially if t
On Sun, Jul 28, 2019 at 03:39:49PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> > deriving additional key material from the fscrypt master key
On Sun, Jul 28, 2019 at 05:17:30PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:35PM -0700, Eric Biggers wrote:
> > @@ -319,6 +329,31 @@ int fscrypt_ioctl_add_key(struct file *filp, void
> > __user *_uarg)
> > if (!capable(CAP_SYS_ADMIN))
> > goto out_wipe_secret;
On Sun, Jul 28, 2019 at 10:00:09PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:41PM -0700, Eric Biggers wrote:
> > +- The kernel cannot magically wipe copies of the master key(s) that
> > + userspace might have as well. Therefore, userspace must wipe all
> > + copies of the ma
On Mon, 2019-07-29 at 13:29 -0700, Eric Biggers wrote:
> On Sun, Jul 28, 2019 at 03:39:49PM -0400, Theodore Y. Ts'o wrote:
> > On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> > > From: Eric Biggers
[...]
> > > HKDF solves all the above problems.
> > >
> > > Signed-off-by: Eric Big
> > Interesting as the inside-secure driver also advertises this ciphersuite
> > and does not
> generate such
> > an error. My guess is you get an error here because plen is not a multiple
> > of 16 and this
> is CBC
> > (note to self: for block ciphers, emphasize legal lengths in the
> > rando
On Mon, Jul 29, 2019 at 10:16:48PM +, Pascal Van Leeuwen wrote:
>
> > EINVAL is for invalid lengths while EBADMSG is for inauthentic inputs.
> > Inauthentic test vectors aren't yet automatically generated (even after this
> > patch), so I don't think EBADMSG should be seen here. Are you sure t
> -Original Message-
> From: Eric Biggers
> Sent: Monday, July 29, 2019 8:23 PM
> To: Pascal Van Leeuwen
> Cc: Pascal van Leeuwen ; linux-crypto@vger.kernel.org;
> herb...@gondor.apana.org.au; da...@davemloft.net
> Subject: Re: [PATCH] crypto: testmgr - Improve randomization of params for
Mark switch cases where we are expecting to fall through.
This patch fixes the following warning (Building: arm):
drivers/crypto/ux500/cryp/cryp.c: In function ‘cryp_save_device_context’:
drivers/crypto/ux500/cryp/cryp.c:316:16: warning: this statement may fall
through [-Wimplicit-fallthrough=]
Herbert,
> -Original Message-
> From: Herbert Xu
> Sent: Tuesday, July 30, 2019 12:31 AM
> To: Pascal Van Leeuwen
> Cc: Eric Biggers ; Pascal van Leeuwen
> ; linux-
> cry...@vger.kernel.org; da...@davemloft.net
> Subject: Re: [PATCH] crypto: testmgr - Improve randomization of params for
On Mon, Jul 29, 2019 at 10:49:38PM +, Pascal Van Leeuwen wrote:
> Herbert,
>
> > -Original Message-
> > From: Herbert Xu
> > Sent: Tuesday, July 30, 2019 12:31 AM
> > To: Pascal Van Leeuwen
> > Cc: Eric Biggers ; Pascal van Leeuwen
> > ; linux-
> > cry...@vger.kernel.org; da...@dave
On Mon, Jul 29, 2019 at 10:16:48PM +, Pascal Van Leeuwen wrote:
> > > > Note that the "empty test suite" message shouldn't be printed
> > > > (especially not at
> > > > KERN_ERR level!) if it's working as intended.
> > > >
> > > That's not my code, that was already there. I already got these m
> -Original Message-
> From: Eric Biggers
> Sent: Tuesday, July 30, 2019 2:17 AM
> To: Pascal Van Leeuwen
> Cc: Pascal van Leeuwen ; linux-crypto@vger.kernel.org;
> herb...@gondor.apana.org.au; da...@davemloft.net
> Subject: Re: [PATCH] crypto: testmgr - Improve randomization of params fo
On 07/26, Eric Biggers wrote:
> From: Eric Biggers
>
> Wire up the new ioctls for adding and removing fscrypt keys to/from the
> filesystem, and the new ioctl for retrieving v2 encryption policies.
>
> FS_IOC_REMOVE_ENCRYPTION_KEY also required making f2fs_drop_inode() call
> fscrypt_drop_inode(
> > You're the expert, but shouldn't there be some priority to the checks
> > being performed? To me, it seems reasonable to do things like length
> > checks prior to even *starting* decryption and authentication.
> > Therefore, it makes more sense to get -EINVAL than -EBADMSG in this
> > case. IMH
On Fri, Jul 26, 2019 at 03:41:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Wire up the new ioctls for adding and removing fscrypt keys to/from the
> filesystem, and the new ioctl for retrieving v2 encryption policies.
>
> FS_IOC_REMOVE_ENCRYPTION_KEY also required making UBIFS use
>
On Tue, Jul 30, 2019 at 12:37:06AM +, Pascal Van Leeuwen wrote:
> > > You're the expert, but shouldn't there be some priority to the checks
> > > being performed? To me, it seems reasonable to do things like length
> > > checks prior to even *starting* decryption and authentication.
> > > There
> > > Oh, I see. Currently the fuzz tests assume that if encryption fails with
> > > an
> > > error (such as EINVAL), then decryption fails with that same error.
> > >
> > Ah ok, oops. It should really log the error that was returned by the
> > generic decryption instead. Which should just be a m
On Mon, Jul 29, 2019 at 12:47:21PM -0700, Tejun Heo wrote:
> On Thu, Jul 25, 2019 at 05:24:59PM -0400, Daniel Jordan wrote:
> > Change the calling convention for apply_workqueue_attrs to require CPU
> > hotplug read exclusion.
> >
> > Avoids lockdep complaints about nested calls to get_online_cpus
On Tue, Jul 30, 2019 at 01:26:17AM +, Pascal Van Leeuwen wrote:
> > > > Oh, I see. Currently the fuzz tests assume that if encryption fails
> > > > with an
> > > > error (such as EINVAL), then decryption fails with that same error.
> > > >
> > > Ah ok, oops. It should really log the error tha
IV transfer from ofifo to class2 (set up at [29][30]) is not guaranteed
to be scheduled before the data transfer from ofifo to external memory
(set up at [38]:
[29] 10FA0004 ld: ind-nfifo (len=4) imm
[30] 81F00010 class2 type=msg len=16>
[31] 14820004 ld: ccb2-dat
53 matches
Mail list logo
