Re: [PATCH v7] printk: hash addresses printed with %p

On Tue, Oct 24, 2017 at 2:31 AM, Tobin C. Harding <m...@tobin.cc> wrote: > On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote: >> Provided you've tested this and the static_key guard stuff actually >> works as intended, > > I tested by inserting a simp

Re: [PATCH v7] printk: hash addresses printed with %p

On Tue, Oct 24, 2017 at 2:31 AM, Tobin C. Harding wrote: > On Tue, Oct 24, 2017 at 01:00:03AM +0200, Jason A. Donenfeld wrote: >> Provided you've tested this and the static_key guard stuff actually >> works as intended, > > I tested by inserting a simple module that calls

Re: [PATCH v7] printk: hash addresses printed with %p

Provided you've tested this and the static_key guard stuff actually works as intended, for the crypto/rng/siphash aspects: Reviewed-by: Jason A. Donenfeld <ja...@zx2c4.com>

Re: [PATCH v7] printk: hash addresses printed with %p

Provided you've tested this and the static_key guard stuff actually works as intended, for the crypto/rng/siphash aspects: Reviewed-by: Jason A. Donenfeld

[PATCH] mips/smp-cmp: use right include for task_struct

(idle); ^~ Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: sta...@vger.kernel.org --- arch/mips/kernel/smp-cmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c index 05295a

[PATCH] mips/smp-cmp: use right include for task_struct

(idle); ^~ Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- arch/mips/kernel/smp-cmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c index 05295a4909f1..415e4d19f897 100644

Re: [PATCH 1/2] random: always call random ready function

Good tips, thanks. I'll wait for more comments before resubmitting v2, but in-progress changes live here: https://git.zx2c4.com/linux-dev/log/?h=jd/cleaner-add-random-ready

Re: [PATCH 1/2] random: always call random ready function

Good tips, thanks. I'll wait for more comments before resubmitting v2, but in-progress changes live here: https://git.zx2c4.com/linux-dev/log/?h=jd/cleaner-add-random-ready

Re: [PATCH] lib/int_sqrt.c: optimize for small argument values

On Thu, Oct 19, 2017 at 10:42 PM, Kees Cook wrote: > Maybe a stupid question, but is this function ultimately used by any > crypto that expects it to be constant-time for safety? Indeed constant time functions for crypto are important. But in this case, it's unlikely this

Re: [PATCH] lib/int_sqrt.c: optimize for small argument values

On Thu, Oct 19, 2017 at 10:42 PM, Kees Cook wrote: > Maybe a stupid question, but is this function ultimately used by any > crypto that expects it to be constant-time for safety? Indeed constant time functions for crypto are important. But in this case, it's unlikely this function would ever be

Re: [PATCH 1/2] random: always call random ready function

These are mostly untested, but I wanted to spec it out for a taste of what it looks like.

Re: [PATCH 1/2] random: always call random ready function

These are mostly untested, but I wanted to spec it out for a taste of what it looks like.

[PATCH 2/2] crypto/drbg: account for no longer returning -EALREADY

We now structure things in a way that assumes the seeding function is always eventually called. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/drbg.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c

[PATCH 2/2] crypto/drbg: account for no longer returning -EALREADY

We now structure things in a way that assumes the seeding function is always eventually called. Signed-off-by: Jason A. Donenfeld --- crypto/drbg.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 70018397e59a

[PATCH 1/2] random: always call random ready function

As this interface becomes more heavily used, it will be painful for callers to always need to check for -EALREADY. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/d

[PATCH 1/2] random: always call random ready function

As this interface becomes more heavily used, it will be painful for callers to always need to check for -EALREADY. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/char/random.c b

Re: [PATCH v5] printk: hash addresses printed with %p

> Tangent: why is the random_ready API designed with -EALREADY? Couldn't > add_random_ready_callback() just perform the call itself and avoid > needing all the callers to check for -EALREADY? Absolutely. I can submit a patch for this soon, though to avoid merge dependencies, and given the usual

Re: [PATCH v5] printk: hash addresses printed with %p

> Tangent: why is the random_ready API designed with -EALREADY? Couldn't > add_random_ready_callback() just perform the call itself and avoid > needing all the callers to check for -EALREADY? Absolutely. I can submit a patch for this soon, though to avoid merge dependencies, and given the usual

Re: [PATCH v5] printk: hash addresses printed with %p

A small detail carried over from the other thread: > > but a bigger problem might the following thing: > > vscnprintf() > pointer() > ptr_to_id() >initialize_ptr_secret() > get_random_bytes() > _get_random_bytes() > extract_crng() >_extract_crng() >

Re: [PATCH v5] printk: hash addresses printed with %p

A small detail carried over from the other thread: > > but a bigger problem might the following thing: > > vscnprintf() > pointer() > ptr_to_id() >initialize_ptr_secret() > get_random_bytes() > _get_random_bytes() > extract_crng() >_extract_crng() >

Re: [PATCH v5] printk: hash addresses printed with %p

On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky <sergey.senozhatsky.w...@gmail.com> wrote: > On (10/19/17 03:03), Jason A. Donenfeld wrote: > [..] >> 1) Go back to the spinlock yourself. > > so we ruled out NMI deadlocks? Oh, right. No, I haven't thought through th

Re: [PATCH v5] printk: hash addresses printed with %p

On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky wrote: > On (10/19/17 03:03), Jason A. Donenfeld wrote: > [..] >> 1) Go back to the spinlock yourself. > > so we ruled out NMI deadlocks? Oh, right. No, I haven't thought through this enough to rule it out. Indeed if that's a

Re: [PATCH v5] printk: hash addresses printed with %p

On Wed, Oct 18, 2017 at 11:30 PM, Tobin C. Harding wrote: > +static siphash_key_t ptr_secret __read_mostly; > +static atomic_t have_key = ATOMIC_INIT(0); > + > +static void initialize_ptr_secret(void) > +{ > + if (atomic_read(_key) == 1) > + return; > + > +

Re: [PATCH v5] printk: hash addresses printed with %p

On Wed, Oct 18, 2017 at 11:30 PM, Tobin C. Harding wrote: > +static siphash_key_t ptr_secret __read_mostly; > +static atomic_t have_key = ATOMIC_INIT(0); > + > +static void initialize_ptr_secret(void) > +{ > + if (atomic_read(_key) == 1) > + return; > + > +

Re: [kernel-hardening] [PATCH v3] printk: hash addresses printed with %p

Hi Tobin, You submitted v3 without replying to my v2 comments. I'll give a condensed version of those here for convenience. > diff --git a/include/linux/siphash.h b/include/linux/siphash.h > +unsigned long siphash_1ulong(const unsigned long a, const siphash_key_t > *key); Don't add this

Re: [kernel-hardening] [PATCH v3] printk: hash addresses printed with %p

Hi Tobin, You submitted v3 without replying to my v2 comments. I'll give a condensed version of those here for convenience. > diff --git a/include/linux/siphash.h b/include/linux/siphash.h > +unsigned long siphash_1ulong(const unsigned long a, const siphash_key_t > *key); Don't add this

Re: [PATCH v2] printk: hash addresses printed with %p

Hi Tobin, Many comments in line below. On Tue, Oct 17, 2017 at 6:52 AM, Tobin C. Harding wrote: > > diff --git a/include/linux/siphash.h b/include/linux/siphash.h > index fa7a6b9cedbf..a9392568c8b8 100644 > --- a/include/linux/siphash.h > +++ b/include/linux/siphash.h > @@ -26,6

Re: [PATCH v2] printk: hash addresses printed with %p

Hi Tobin, Many comments in line below. On Tue, Oct 17, 2017 at 6:52 AM, Tobin C. Harding wrote: > > diff --git a/include/linux/siphash.h b/include/linux/siphash.h > index fa7a6b9cedbf..a9392568c8b8 100644 > --- a/include/linux/siphash.h > +++ b/include/linux/siphash.h > @@ -26,6 +26,8 @@ u64

Re: [PATCH 0/3] add %pX specifier

On Wed, Oct 11, 2017 at 11:29 PM, Linus Torvalds wrote: > Yeah, siphash is probably the sanest thing to use. > > How bad would it be to use HalfSipHash on 32-bit architectures? > > On a 32-bit machine, the full siphash is pretty expensive - big > constants, and lots

Re: [PATCH 0/3] add %pX specifier

On Wed, Oct 11, 2017 at 11:29 PM, Linus Torvalds wrote: > Yeah, siphash is probably the sanest thing to use. > > How bad would it be to use HalfSipHash on 32-bit architectures? > > On a 32-bit machine, the full siphash is pretty expensive - big > constants, and lots of 64-bit shifts. And 32-bit

Re: [PATCH 0/3] add %pX specifier

Hi Linus, On Wed, Oct 11, 2017 at 1:15 AM, Linus Torvalds wrote: > (NOTE! Using jhash here is not acceptable, since it's not > cryptographically safe, but think of it as an example of a hash that > takes 32-bit input). Ahh, yes, I should have continued to read the

Re: [PATCH 0/3] add %pX specifier

Hi Linus, On Wed, Oct 11, 2017 at 1:15 AM, Linus Torvalds wrote: > (NOTE! Using jhash here is not acceptable, since it's not > cryptographically safe, but think of it as an example of a hash that > takes 32-bit input). Ahh, yes, I should have continued to read the thread before replying my

Re: [PATCH 0/3] add %pX specifier

Hi Tobin, On Wed, Oct 11, 2017 at 1:09 AM, Tobin C. Harding wrote: > > +hashval = hash_three_words( > +(unsigned long)ptr, > +(unsigned long)ptr >> 16 >> 16, > +boot_time_random_int); This is most likely not what you

Re: [PATCH 0/3] add %pX specifier

Hi Tobin, On Wed, Oct 11, 2017 at 1:09 AM, Tobin C. Harding wrote: > > +hashval = hash_three_words( > +(unsigned long)ptr, > +(unsigned long)ptr >> 16 >> 16, > +boot_time_random_int); This is most likely not what you want to be

Re: [PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

Hi Herbert, Can we get this reviewed for rc5 please? Thanks, Jason

Re: [PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

Hi Herbert, Can we get this reviewed for rc5 please? Thanks, Jason

Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs

On Mon, Oct 9, 2017 at 2:31 PM, Johannes Berg wrote: > > Reviewed-by: Johannes Berg Thanks for the review. Hopefully this can make it into 4.13.6 and 4.14-rc5.

Re: [PATCH v2] netlink: do not set cb_running if dump's start() errs

On Mon, Oct 9, 2017 at 2:31 PM, Johannes Berg wrote: > > Reviewed-by: Johannes Berg Thanks for the review. Hopefully this can make it into 4.13.6 and 4.14-rc5.

[PATCH v2] netlink: do not set cb_running if dump's start() errs

of this logic. In testing this with several different pieces of tricky code to trigger these issues, this commit fixes all avenues that I'm aware of. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Johannes Berg <johan...@sipsolutions.net> --- net/netlink/af_netlink.c | 13

[PATCH v2] netlink: do not set cb_running if dump's start() errs

of this logic. In testing this with several different pieces of tricky code to trigger these issues, this commit fixes all avenues that I'm aware of. Signed-off-by: Jason A. Donenfeld Cc: Johannes Berg --- net/netlink/af_netlink.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions

Re: [PATCH] netlink: do not set cb_running if dump's start() errs

Hi Johannes, Yes, indeed, and I think that's actually a good thing. It means that the starts aren't ever called in parallel, which could be useful if drivers have any ordering requirements. The change doesn't negatively effect any existing drivers. I'll resubmit with a larger commit message

Re: [PATCH] netlink: do not set cb_running if dump's start() errs

Hi Johannes, Yes, indeed, and I think that's actually a good thing. It means that the starts aren't ever called in parallel, which could be useful if drivers have any ordering requirements. The change doesn't negatively effect any existing drivers. I'll resubmit with a larger commit message

[PATCH] netlink: do not set cb_running if dump's start() errs

no chance at all of hitting the dump() function through any indirect paths. In testing this with several different pieces of tricky code to trigger these issues, this commit fixes all avenues that I'm aware of. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Johannes Berg

Re: [PATCH] netlink: do not set cb_running if dump's start() errs

Dave - this very likely should be queued up for stable. Jason

[PATCH] netlink: do not set cb_running if dump's start() errs

no chance at all of hitting the dump() function through any indirect paths. In testing this with several different pieces of tricky code to trigger these issues, this commit fixes all avenues that I'm aware of. Signed-off-by: Jason A. Donenfeld Cc: Johannes Berg --- net/netlink/af_netlink.c | 13

Re: [PATCH] netlink: do not set cb_running if dump's start() errs

Dave - this very likely should be queued up for stable. Jason

Re: netlink backwards compatibility in userspace tools

Hi Dave, That seems wise. Thanks for the advice. A more sophisticated way of approaching this would be for the kernel to also send a bitmap of which attributes are "critical" and only warn (or even error) of _those_ are not understood. But that seems needlessly complex, and so I think I'll go

Re: netlink backwards compatibility in userspace tools

Hi Dave, That seems wise. Thanks for the advice. A more sophisticated way of approaching this would be for the kernel to also send a bitmap of which attributes are "critical" and only warn (or even error) of _those_ are not understood. But that seems needlessly complex, and so I think I'll go

Re: [PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

s/objdump/objtool/g obviously.

Re: [PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

s/objdump/objtool/g obviously.

[PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

This fixes things up to use code similar to gcc's DRAP register, so that objdump remains happy. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Fixes: baa41469a7b9 ("objtool: Implement stack validation 2.0") --- arch/x86/crypto/chacha20-avx2-x86_64.S | 4 ++-- arch/x86/crypto/chacha2

[PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

This fixes things up to use code similar to gcc's DRAP register, so that objdump remains happy. Signed-off-by: Jason A. Donenfeld Fixes: baa41469a7b9 ("objtool: Implement stack validation 2.0") --- arch/x86/crypto/chacha20-avx2-x86_64.S | 4 ++-- arch/x86/crypto/chacha20-ssse3-x86_64.S | 4 ++-

multi producer / multi consumer lock-free queue with ptr_ring

Hey Michael, Thanks for your work on ptr_ring.h. I'm interested in using it, but in a multi-producer, multi-consumer context. I realize it's been designed for a single-producer, single-consumer context, and thus uses a spinlock. I'm wondering if you'd be happy to receive patches that implement

multi producer / multi consumer lock-free queue with ptr_ring

Hey Michael, Thanks for your work on ptr_ring.h. I'm interested in using it, but in a multi-producer, multi-consumer context. I realize it's been designed for a single-producer, single-consumer context, and thus uses a spinlock. I'm wondering if you'd be happy to receive patches that implement

netlink backwards compatibility in userspace tools

Hi guys, One handy aspect of Netlink is that it's backwards compatible. This means that you can run old userspace utilities on new kernels, even if the new kernel supports new features and netlink attributes. The wire format is stable enough that the data marshaled can be extended without

netlink backwards compatibility in userspace tools

Hi guys, One handy aspect of Netlink is that it's backwards compatible. This means that you can run old userspace utilities on new kernels, even if the new kernel supports new features and netlink attributes. The wire format is stable enough that the data marshaled can be extended without

Re: [GIT PULL] security: keys fixes for v4.14-rc3

On Fri, Sep 29, 2017 at 12:33 AM, James Morris wrote: > Generally speaking, we likely need to improve the amount of crypto review > for kernel crypto users including keys (I'll post a note separately to > ksummit-discuss). Indeed. I won't be at kernel summit, regrettably, but

Re: [GIT PULL] security: keys fixes for v4.14-rc3

On Fri, Sep 29, 2017 at 12:33 AM, James Morris wrote: > Generally speaking, we likely need to improve the amount of crypto review > for kernel crypto users including keys (I'll post a note separately to > ksummit-discuss). Indeed. I won't be at kernel summit, regrettably, but I do intend to

Re: [PATCH v2] netlink: do not proceed if dump's start() errs

On Thu, Sep 28, 2017 at 12:41:44AM +0200, Jason A. Donenfeld wrote: > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c > index 327807731b44..94c11cf0459d 100644 > --- a/net/netlink/af_netlink.c > +++ b/net/netlink/af_netlink.c > @@ -2270,10 +2270,13 @@ int __net

Re: [PATCH v2] netlink: do not proceed if dump's start() errs

On Thu, Sep 28, 2017 at 12:41:44AM +0200, Jason A. Donenfeld wrote: > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c > index 327807731b44..94c11cf0459d 100644 > --- a/net/netlink/af_netlink.c > +++ b/net/netlink/af_netlink.c > @@ -2270,10 +2270,13 @@ int __net

[PATCH v2] netlink: do not proceed if dump's start() errs

noring it. This patch thus returns early and does not call dumpit() when start() fails. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Johannes Berg <johan...@sipsolutions.net> --- net/netlink/af_netlink.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff -

[PATCH v2] netlink: do not proceed if dump's start() errs

noring it. This patch thus returns early and does not call dumpit() when start() fails. Signed-off-by: Jason A. Donenfeld Cc: Johannes Berg --- net/netlink/af_netlink.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c

Re: [PATCH] netlink: do not proceed if dump's start() errs

On Wed, Sep 27, 2017 at 3:05 PM, Johannes Berg wrote: > I guess you could change it to > > if (cb->start) > ret = cb->start(cb); > if (!ret) > ret = netlink_dump(sk); Very clean. I'll do it like that. I'll wait a bit longer before submitting v2, but

Re: [PATCH] netlink: do not proceed if dump's start() errs

On Wed, Sep 27, 2017 at 3:05 PM, Johannes Berg wrote: > I guess you could change it to > > if (cb->start) > ret = cb->start(cb); > if (!ret) > ret = netlink_dump(sk); Very clean. I'll do it like that. I'll wait a bit longer before submitting v2, but beyond that, seems sane to

Re: [PATCH] netlink: do not proceed if dump's start() errs

On Wed, Sep 27, 2017 at 2:39 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > - if (cb->start) > - cb->start(cb); > + if (cb->start) { > + ret = cb->start(cb); > + if (ret) I need to sock_put(sk); befor

Re: [PATCH] netlink: do not proceed if dump's start() errs

On Wed, Sep 27, 2017 at 2:39 PM, Jason A. Donenfeld wrote: > - if (cb->start) > - cb->start(cb); > + if (cb->start) { > + ret = cb->start(cb); > + if (ret) I need to sock_put(sk); before retu

[PATCH] netlink: do not proceed if dump's start() errs

noring it. This patch thus returns early and does not call dumpit() when start() fails. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: sta...@vger.kernel.org --- net/netlink/af_netlink.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/netlink/af_net

[PATCH] netlink: do not proceed if dump's start() errs

noring it. This patch thus returns early and does not call dumpit() when start() fails. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- net/netlink/af_netlink.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/net/netlink/af_netlink.c b/net/n

Re: [PATCH v7 2/2] security/keys: rewrite all of big_key crypto

On Mon, Sep 25, 2017 at 4:43 PM, David Howells <dhowe...@redhat.com> wrote: > Jason A. Donenfeld <ja...@zx2c4.com> wrote: > >> + /* no ->update(); don't add it without changing big_key_crypt() nonce >> */ > > Should update be a problem. It's should be

Re: [PATCH v7 2/2] security/keys: rewrite all of big_key crypto

On Mon, Sep 25, 2017 at 4:43 PM, David Howells wrote: > Jason A. Donenfeld wrote: > >> + /* no ->update(); don't add it without changing big_key_crypt() nonce >> */ > > Should update be a problem. It's should be a complete payload replacement - > kind of li

[PATCH v7 1/2] security/keys: properly zero out sensitive key material in big_key

Error paths forgot to zero out sensitive material, so this patch changes some kfrees into a kzfrees. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Eric Biggers <ebigge...@gmail.com> Cc: David Howells <dhowe...@redhat.com> Cc: Herbert Xu <herb...@gondor.apa

[PATCH v7 1/2] security/keys: properly zero out sensitive key material in big_key

Error paths forgot to zero out sensitive material, so this patch changes some kfrees into a kzfrees. Signed-off-by: Jason A. Donenfeld Reviewed-by: Eric Biggers Cc: David Howells Cc: Herbert Xu Cc: Kirill Marinushkin Cc: secur...@kernel.org Cc: sta...@vger.kernel.org --- security/keys

[PATCH v7 2/2] security/keys: rewrite all of big_key crypto

the plaintext, which is is even more frightening considering the next point. * Use of ECB mode, allowing an attacker to trivially swap blocks or compare identical plaintext blocks. * Key re-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by

[PATCH v7 2/2] security/keys: rewrite all of big_key crypto

the plaintext, which is is even more frightening considering the next point. * Use of ECB mode, allowing an attacker to trivially swap blocks or compare identical plaintext blocks. * Key re-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld Reviewed-by: Eric Biggers Cc: David

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Tue, Sep 19, 2017 at 5:38 PM, David Howells <dhowe...@redhat.com> wrote: > Jason A. Donenfeld <ja...@zx2c4.com> wrote: > >> And, some error paths forgot to zero out sensitive >> material, so this patch changes a kfree into a kzfree. > > Can you split that o

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Tue, Sep 19, 2017 at 5:38 PM, David Howells wrote: > Jason A. Donenfeld wrote: > >> And, some error paths forgot to zero out sensitive >> material, so this patch changes a kfree into a kzfree. > > Can you split that out into a separate preparatory patch? > &

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 4:06 PM, Stephan Mueller wrote: >> Section 3 shows an attack with repeated nonces, which we don't do here. > > Maybe I miss a point here, but zero IVs is no repetition of nonces? If there's a fresh key each time, then no, it's not a repetition. This

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 4:06 PM, Stephan Mueller wrote: >> Section 3 shows an attack with repeated nonces, which we don't do here. > > Maybe I miss a point here, but zero IVs is no repetition of nonces? If there's a fresh key each time, then no, it's not a repetition. This patch uses a fresh

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 3:45 PM, Stephan Mueller wrote: > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.pdf Section 3 shows an attack with repeated nonces, which we don't do here. Section 4 shows an attack using a non-96-bit nonce, which we also don't

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 3:45 PM, Stephan Mueller wrote: > http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/Joux_comments.pdf Section 3 shows an attack with repeated nonces, which we don't do here. Section 4 shows an attack using a non-96-bit nonce, which we also don't do here.

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 7:30 AM, Stephan Mueller wrote: > The use of GCM with the implementtion here is just as challenging. The > implementation uses a NULL IV. GCM is a very brittle cipher where the > construction of the IV is of special importance. SP800-38D section 8.2.1

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

On Wed, Sep 20, 2017 at 7:30 AM, Stephan Mueller wrote: > The use of GCM with the implementtion here is just as challenging. The > implementation uses a NULL IV. GCM is a very brittle cipher where the > construction of the IV is of special importance. SP800-38D section 8.2.1 and > 8.2.2 outlines

Re: [kernel-hardening] Re: [PATCH v4] security/keys: rewrite all of big_key crypto

On Tue, Sep 19, 2017 at 9:04 PM, Sandy Harris wrote: > On the other hand, I do not see why the driver should not >From my perspective, this discussion is over. I'll be carrying out David's requested patchset changes and submitting it. If you'd like different cryptography,

Re: [kernel-hardening] Re: [PATCH v4] security/keys: rewrite all of big_key crypto

On Tue, Sep 19, 2017 at 9:04 PM, Sandy Harris wrote: > On the other hand, I do not see why the driver should not >From my perspective, this discussion is over. I'll be carrying out David's requested patchset changes and submitting it. If you'd like different cryptography, you'll have to find

Re: [PATCH v4] security/keys: rewrite all of big_key crypto

Hello Stephan, I realize you have your Linux RNG project, which is a very worthwhile goal that I support you in. I hope you're eventually successful, and I apologize for not being more available in the last 2.5 months to chime in on that patchset thread you posted. However, your message to this

Re: [PATCH v4] security/keys: rewrite all of big_key crypto

Hello Stephan, I realize you have your Linux RNG project, which is a very worthwhile goal that I support you in. I hope you're eventually successful, and I apologize for not being more available in the last 2.5 months to chime in on that patchset thread you posted. However, your message to this

[PATCH v6] security/keys: rewrite all of big_key crypto

-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Eric Biggers <ebigge...@gmail.com> Cc: David Howells <dhowe...@redhat.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: Kirill Marinushkin <k.marinush...@gmail.com> C

[PATCH v6] security/keys: rewrite all of big_key crypto

-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld Reviewed-by: Eric Biggers Cc: David Howells Cc: Herbert Xu Cc: Kirill Marinushkin Cc: secur...@kernel.org Cc: sta...@vger.kernel.org --- security/keys/Kconfig | 4 +- security/keys/big_key.c | 139

Re: [PATCH v5] security/keys: rewrite all of big_key crypto

On Sun, Sep 17, 2017 at 8:04 AM, Eric Biggers wrote: > This should jump to 'err_enckey', otherwise it will leak 'enckey'. Yikes, good catch, thanks! > > Otherwise the changes all look good; after fixing the above, feel free to add > my > Reviewed-by. Ack. > Yes, AES-GCM

Re: [PATCH v5] security/keys: rewrite all of big_key crypto

On Sun, Sep 17, 2017 at 8:04 AM, Eric Biggers wrote: > This should jump to 'err_enckey', otherwise it will leak 'enckey'. Yikes, good catch, thanks! > > Otherwise the changes all look good; after fixing the above, feel free to add > my > Reviewed-by. Ack. > Yes, AES-GCM is the right choice

[PATCH v5] security/keys: rewrite all of big_key crypto

-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> Cc: Eric Biggers <ebigge...@gmail.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: Kirill Marinushkin <k.marinush...@gmail.com> C

[PATCH v5] security/keys: rewrite all of big_key crypto

-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Eric Biggers Cc: Herbert Xu Cc: Kirill Marinushkin Cc: secur...@kernel.org Cc: sta...@vger.kernel.org --- security/keys/Kconfig | 4 +- security/keys/big_key.c | 141

[PATCH v4] security/keys: rewrite all of big_key crypto

-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> Cc: Eric Biggers <ebigge...@gmail.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: Kirill Marinushkin <k.marinush...@gmail.com> C

[PATCH v4] security/keys: rewrite all of big_key crypto

-use. * Faulty memory zeroing. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Eric Biggers Cc: Herbert Xu Cc: Kirill Marinushkin Cc: Ard Biesheuvel Cc: Ilhan Gurel Cc: secur...@kernel.org Cc: sta...@vger.kernel.org --- security/keys/Kconfig | 4 +- security/keys/big_key.c

[PATCH] bluetooth/smp: ensure RNG is properly seeded before ECDH use

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Marcel Holtmann <mar...@holtmann.org> Cc: Gustavo P

[PATCH] bluetooth/smp: ensure RNG is properly seeded before ECDH use

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg --- net/bluetooth

[PATCH] crypto/rng: ensure that the RNG is ready before using

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c index 5e8469244960..b4a618668161 100644 --- a/crypto/rng.c +++ b/crypto/rng.c @@ -43,12 +43,14 @@ int crypto_rng_reset(struc

[PATCH] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. The one use of this function from within the kernel -- not from userspace -- is being removed (keys/big_key), so that call site isn't relevant in assessing this. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld

[PATCH] security/keys: ensure RNG is seeded before use

a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> Cc: Mi

[PATCH] security/keys: ensure RNG is seeded before use

a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Mimi Zohar Cc: David Safford --- security/keys

<    1   2   3   4   5   6   7   8   9   10   >