On Wed, Nov 29, 2017 at 09:38:52AM -0800, Florian Fainelli wrote:
>
> Hu, okay, I actually had a v3 prepared that I was going to post
> addressing some of the comments. Should I send an incremental set of
> changes now?
Please send it as an incremental set.
Thanks,
--
Email: Herbert Xu
Home Pag
On Wed, Nov 29, 2017 at 11:51:09AM -0800, Eric Biggers wrote:
>
> Herbert, if it's not too late can you fix the subject? It got split into two
> lines:
Sorry, it's already pushed out with other patches sitting on top
of it.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~he
On Wed, Nov 29, 2017 at 04:23:53PM +1100, Herbert Xu wrote:
> On Tue, Nov 28, 2017 at 01:02:52AM -0800, Eric Biggers wrote:
> >
> > >From 1a7a7f86f09c50652f1fff75b8d3a32712826b32 Mon Sep 17 00:00:00 2001
> > From: Eric Biggers
> > Date: Tue, 28 Nov 2017 00:46:24 -0800
> > Subject: [PATCH] crypto:
On Wed, Nov 29, 2017 at 11:30:36AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
wrote:
> On Wed, Nov 29, 2017 at 11:24 AM, syzbot
>
> wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 43570f0383d6d5879ae585e6c3cf027ba321546f
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds
On 11/28/2017 10:30 PM, Herbert Xu wrote:
> On Tue, Nov 07, 2017 at 04:44:38PM -0800, Florian Fainelli wrote:
>> In preparation for consolidating bcm63xx-rng into bcm2835-rng, make sure
>> that we obtain the base register via platform_get_resource() since we
>> need to support the non-DT enabled MI
On Wed, Nov 29, 2017 at 12:05:13PM +0100, Stephan Müller wrote:
>
> Shouldn't we then create a patch for the pre-4.14 algif_skcipher code that
> moves the wait out of the while loop to the beginning of the function in
> recvmsg?
When I said dead-lock I just meant that the recvmsg will block
inde
Am Mittwoch, 29. November 2017, 08:10:49 CET schrieb Herbert Xu:
Hi Herbert,
>
> It sort of worked for skcipher because it didn't care if ctx->enc
> or even ctx->iv changed midstream. But even there I don't think
> we need to wait a second time. In fact waiting a second time could
> result in
The wait for data is a non-atomic operation that can sleep and therefore
potentially release the socket lock. The release of the socket lock
allows another thread to modify the context data structure. The waiting
operation for new data therefore must be called at the beginning of
recvmsg. This prev
On Wed, Nov 29, 2017 at 11:28:43AM +0100, Stephan Mueller wrote:
> Am Mittwoch, 29. November 2017, 11:22:34 CET schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Wed, Nov 29, 2017 at 11:17:26AM +0100, Stephan Müller wrote:
> > > @@ -111,6 +111,12 @@ static int _aead_recvmsg(struct socket *sock, struct
On Wed, Nov 29, 2017 at 11:24 AM, syzbot
wrote:
> Hello,
>
> syzkaller hit the following crash on
> 43570f0383d6d5879ae585e6c3cf027ba321546f
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is
Am Mittwoch, 29. November 2017, 11:22:34 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Nov 29, 2017 at 11:17:26AM +0100, Stephan Müller wrote:
> > @@ -111,6 +111,12 @@ static int _aead_recvmsg(struct socket *sock, struct
> > msghdr *msg,>
> > size_t usedpages = 0; /* [in] RX bufs
On Wed, Nov 29, 2017 at 11:17:26AM +0100, Stephan Müller wrote:
>
> @@ -111,6 +111,12 @@ static int _aead_recvmsg(struct socket *sock, struct
> msghdr *msg,
> size_t usedpages = 0; /* [in] RX bufs to be used from user */
> size_t processed = 0; /* [in] TX bufs to
On Wed, Nov 29, 2017 at 08:57:33AM +, Horia Geantă wrote:
>
> Considering this fixes the crash reported by Tudor:
> https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg29172.html
> I think it should be merged in this release cycle (v4.15).
This only affects tcrypt right? Since tcrypt
The wait for data is a non-atomic operation that can sleep and therefore
potentially release the socket lock. The release of the socket lock
allows another thread to modify the context data structure. The waiting
operation for new data therefore must be called at the beginning of
recvmsg. This prev
On Tue, Nov 28, 2017 at 06:22:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
From: Eric Biggers
All the ChaCha20 algorithms as well as the ARM bit-sliced AES-XTS
algorithms call skcipher_walk_virt(), then access the IV (walk.iv)
before checking whether any bytes need to be processed (walk.nbytes).
But if the input is empty, then skcipher_walk_virt() doesn't set the IV,
a
On Wed, Nov 29, 2017 at 12:33:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 1ea8d039f9edcfefb20d8ddfe136930f6e551529
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> Unfo
On Tue, Nov 28, 2017 at 07:23:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 1ea8d039f9edcfefb20d8ddfe136930f6e551529
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C repro
On 11/29/2017 8:28 AM, Herbert Xu wrote:
> On Tue, Oct 10, 2017 at 01:21:59PM +0300, Robert Baronescu wrote:
>> In case buffer length is a multiple of PAGE_SIZE,
>> the S/G table is incorrectly generated.
>> Fix this by handling buflen = k * PAGE_SIZE separately.
>>
>> Signed-off-by: Robert Barones
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch permit it to enqueue any type of crypto_async_request.
Signed-off-by: Corentin Labbe
---
crypto/crypto_engine.c | 188 +++-
include/crypto/engine.h | 46 +--
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/omap-aes.c | 21 +++--
drivers/crypto/omap-aes.h | 3 +++
drivers/crypto/omap-des.c | 24 ++--
3 files changed, 36 insertions(+), 12 deletions(-)
dif
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/virtio/virtio_crypto_algs.c | 15 ++-
drivers/crypto/virtio/virtio_crypto_common.h | 2 +-
drivers/crypto/virtio/virtio_crypto_core.c | 3 ---
3 files changed, 11 insert
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/stm32/stm32-hash.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-hash.c
b/drivers/crypto/stm32/stm32-hash.c
index
Hello
The current crypto_engine support only ahash and ablkcipher.
My first patch which try to add skcipher was Nacked, it will add too many
functions
and adding other algs(aead, asymetric_key) will make the situation worst.
This patchset remove all algs specific stuff and now only process gener
24 matches
Mail list logo
