[PATCH 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/core/skbuff.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/sk

[PATCH 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee. Signed-off-by: Jason A. Donenfeld --- net/core/skbuff.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index f86bf69cfb8d

Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec

On Mon, Apr 24, 2017 at 1:02 PM, David Laight wrote: > ... > > Shouldn't skb_to_sgvec() be checking the number of fragments against > the size of the sg list? > The callers would then all need auditing to allow for failure. This has never been done before, since this is

Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec

On Mon, Apr 24, 2017 at 1:02 PM, David Laight wrote: > ... > > Shouldn't skb_to_sgvec() be checking the number of fragments against > the size of the sg list? > The callers would then all need auditing to allow for failure. This has never been done before, since this is one of those operations

[PATCH] macsec: avoid heap overflow in skb_to_sgvec

F_F_FRAGLIST, in which case the call to skb_to_sgvec will overflow the heap, and disaster ensues. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: sta...@vger.kernel.org Cc: secur...@kernel.org --- drivers/net/macsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -

[PATCH] macsec: avoid heap overflow in skb_to_sgvec

F_F_FRAGLIST, in which case the call to skb_to_sgvec will overflow the heap, and disaster ensues. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org Cc: secur...@kernel.org --- drivers/net/macsec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/macsec.c b

Re: [patch 03/20] padata: Make padata_alloc() static

I rather like this option of padata, which, since it lives in kernel/padata.c and linux/padata.h, should be generic and useful for other components. Seems like the ability to allocate it for a particular set of worker CPUs and callback CPUs could be useful down the line. Would rather not see it

Re: [patch 03/20] padata: Make padata_alloc() static

I rather like this option of padata, which, since it lives in kernel/padata.c and linux/padata.h, should be generic and useful for other components. Seems like the ability to allocate it for a particular set of worker CPUs and callback CPUs could be useful down the line. Would rather not see it

Re: [PATCH] padata: allow caller to control queue length

On Fri, Apr 14, 2017 at 9:57 AM, Steffen Klassert wrote: > Why do we need this? As long as we don't have a user that needs a > different limit, this patch adds just some useless code. My [not-yet-mainlined] code wants it. But more compellingly, padata simply isn't

Re: [PATCH] padata: allow caller to control queue length

On Fri, Apr 14, 2017 at 9:57 AM, Steffen Klassert wrote: > Why do we need this? As long as we don't have a user that needs a > different limit, this patch adds just some useless code. My [not-yet-mainlined] code wants it. But more compellingly, padata simply isn't a very useful interface if it

[PATCH] padata: allow caller to control queue length

on the 1000-job limit. We do, however, impose a limit on padata so that the reference count does not have an integer overflow. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Documentation/padata.txt | 8 crypto/pcrypt.c | 5 + include/linux/padata.h | 2 ++

[PATCH] padata: allow caller to control queue length

on the 1000-job limit. We do, however, impose a limit on padata so that the reference count does not have an integer overflow. Signed-off-by: Jason A. Donenfeld --- Documentation/padata.txt | 8 crypto/pcrypt.c | 5 + include/linux/padata.h | 2 ++ kernel/padata.c

[PATCH] padata: get_next is never NULL

Per Dan's static checker warning, the code that returns NULL was removed in 2010, so this patch updates the comments and fixes the code assumptions. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reported-by: Dan Carpenter <dan.carpen...@oracle.com> --- kernel/padata.c | 13

[PATCH] padata: get_next is never NULL

Per Dan's static checker warning, the code that returns NULL was removed in 2010, so this patch updates the comments and fixes the code assumptions. Signed-off-by: Jason A. Donenfeld Reported-by: Dan Carpenter --- kernel/padata.c | 13 - 1 file changed, 4 insertions(+), 9 deletions

crypto_memneq not backported to 3.10

Hey Willy, Linux 3.10 is inexplicably missing crypto_memneq, making all crypto mac comparisons use non constant-time comparisons. Bad news bears. 3.12 got these backported with d68e944a8fcb2c6212b38064771c9f5af7b0b92c, afe5a791d374e50a06ada7f4eda4e921e1b77996, and possibly others. I'd suggest

crypto_memneq not backported to 3.10

Hey Willy, Linux 3.10 is inexplicably missing crypto_memneq, making all crypto mac comparisons use non constant-time comparisons. Bad news bears. 3.12 got these backported with d68e944a8fcb2c6212b38064771c9f5af7b0b92c, afe5a791d374e50a06ada7f4eda4e921e1b77996, and possibly others. I'd suggest

for stable -- random: use chacha20 for get_random_int/long

judgement call. commit f5b98461cb8167ba362ad9f74c41d126b7becea7 Author: Jason A. Donenfeld <ja...@zx2c4.com> Date: Fri Jan 6 19:32:01 2017 +0100 random: use chacha20 for get_random_int/long Now that our crng uses chacha20, we can rely on its speedy characteristics for replaci

for stable -- random: use chacha20 for get_random_int/long

judgement call. commit f5b98461cb8167ba362ad9f74c41d126b7becea7 Author: Jason A. Donenfeld Date: Fri Jan 6 19:32:01 2017 +0100 random: use chacha20 for get_random_int/long Now that our crng uses chacha20, we can rely on its speedy characteristics for replacing MD5, while simultaneously

[PATCH] padata: free correct variable

The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: sta...@vger.kernel.org --- kernel/padata.c | 2 +- 1 file changed, 1 ins

[PATCH] padata: free correct variable

The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- kernel/padata.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH] MIPS: IRQ Stack: Unwind IRQ stack onto task stack

This indeed is useful. Out of curiosity, are other archs using a similar technique? In anycase, Acked-by: Jason A. Donenfeld <ja...@zx2c4.com>

Re: [PATCH] MIPS: IRQ Stack: Unwind IRQ stack onto task stack

This indeed is useful. Out of curiosity, are other archs using a similar technique? In anycase, Acked-by: Jason A. Donenfeld

Re: [PATCH] padata: avoid race in reordering

Herbert applied this to his tree. It's probably a good stable candidate, since it's a two line change to fix a race condition. On Fri, Mar 24, 2017 at 3:16 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > Jason A. Donenfeld <ja...@zx2c4.com> wrote: >> Under extremely

Re: [PATCH] padata: avoid race in reordering

Herbert applied this to his tree. It's probably a good stable candidate, since it's a two line change to fix a race condition. On Fri, Mar 24, 2017 at 3:16 PM, Herbert Xu wrote: > Jason A. Donenfeld wrote: >> Under extremely heavy uses of padata, crashes occur, and with list >> d

Re: [PATCH] padata: avoid race in reordering

I've got a few other races in padata, I think, that I'm working on fixing. If these pan out, I'll submit them exclusively to -crypto instead of -netdev, to avoid this confusion next time. Of course, if I'm able to fix these, then I'll probably be bald from pulling my hair out during this insane

Re: [PATCH] padata: avoid race in reordering

I've got a few other races in padata, I think, that I'm working on fixing. If these pan out, I'll submit them exclusively to -crypto instead of -netdev, to avoid this confusion next time. Of course, if I'm able to fix these, then I'll probably be bald from pulling my hair out during this insane

[PATCH] padata: avoid race in reordering

t and subsequently call list_add_tail on them at the same time. The fix is thus be hoist that lock outside of that block. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- kernel/padata.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/padata.c b/kern

[PATCH] padata: avoid race in reordering

t and subsequently call list_add_tail on them at the same time. The fix is thus be hoist that lock outside of that block. Signed-off-by: Jason A. Donenfeld --- kernel/padata.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/padata.c b/kernel/padata.c index 05316c9f32da..32

Re: [PATCH] md5: remove from lib and only live in crypto

POKE?

Re: [PATCH] md5: remove from lib and only live in crypto

POKE?

race condition in kernel/padata.c

Hey Steffen, WireGuard makes really heavy use of padata, feeding it units of work from different cores in different contexts all at the same time. For the most part, everything has been fine, but one particular user has consistently run into mysterious bugs. He's using a rather old dual core CPU,

race condition in kernel/padata.c

Hey Steffen, WireGuard makes really heavy use of padata, feeding it units of work from different cores in different contexts all at the same time. For the most part, everything has been fine, but one particular user has consistently run into mysterious bugs. He's using a rather old dual core CPU,

Google Summer of Code: WireGuard & kernel hacking

Hey guys, WireGuard is accepting students for Google Summer of Code. If you're a student and want to spend the summer writing kernel networking code, cryptography code, security code, and all sorts of interesting things, this might be somewhat appealing to you. A few project ideas are listed

Google Summer of Code: WireGuard & kernel hacking

Hey guys, WireGuard is accepting students for Google Summer of Code. If you're a student and want to spend the summer writing kernel networking code, cryptography code, security code, and all sorts of interesting things, this might be somewhat appealing to you. A few project ideas are listed

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Hey Stephan, Have you considered submitting this without so many options? For example -- just unconditionally using ChaCha20 instead of the configurable crypto API functions? And either removing the FIPS140 compliance code, and either unconditionally including it, or just getting rid of it? And

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

Hey Stephan, Have you considered submitting this without so many options? For example -- just unconditionally using ChaCha20 instead of the configurable crypto API functions? And either removing the FIPS140 compliance code, and either unconditionally including it, or just getting rid of it? And

[PATCH] md5: remove from lib and only live in crypto

there are more modern ways of doing what it once achieved. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- In the last patch like this, we managed to get rid of halfmd4 from this file. In this series we get rid of md5, now that the patches have landed that remove such improper md5 usag

[PATCH] md5: remove from lib and only live in crypto

there are more modern ways of doing what it once achieved. Signed-off-by: Jason A. Donenfeld --- In the last patch like this, we managed to get rid of halfmd4 from this file. In this series we get rid of md5, now that the patches have landed that remove such improper md5 usage from the kernel. When

random-dev misses merge window?

Hey Ted, I was disappointed to see that this series: https://git.kernel.org/cgit/linux/kernel/git/tytso/random.git/log/?h=dev missed 4.11-rc1, especially considering those patches were ready since January, and I had sent you several reminders to even get them merged in your random.git tree. Did

random-dev misses merge window?

Hey Ted, I was disappointed to see that this series: https://git.kernel.org/cgit/linux/kernel/git/tytso/random.git/log/?h=dev missed 4.11-rc1, especially considering those patches were ready since January, and I had sent you several reminders to even get them merged in your random.git tree. Did

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sun, Jan 22, 2017 at 11:28 PM, Theodore Ts'o wrote: > If there are other changes to the relevant lines from the networking > tree, sure. This patch set has *nothing* to do with the networking tree. That just a topic confusion. There shouldn't be more discussion about

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sun, Jan 22, 2017 at 11:28 PM, Theodore Ts'o wrote: > If there are other changes to the relevant lines from the networking > tree, sure. This patch set has *nothing* to do with the networking tree. That just a topic confusion. There shouldn't be more discussion about networking, because it

[PATCH 2/2] random: convert get_random_int/long into get_random_u32/u64

and get_random_long are both aliased to get_random_u32. On 64-bit platforms, int->u32 and long->u64. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Theodore Ts'o <ty...@mit.edu> --- dri

[PATCH 2/2] random: convert get_random_int/long into get_random_u32/u64

and get_random_long are both aliased to get_random_u32. On 64-bit platforms, int->u32 and long->u64. Signed-off-by: Jason A. Donenfeld Cc: Greg Kroah-Hartman Cc: Theodore Ts'o --- drivers/char/random.c | 55 +- include/linux/random.

[PATCH 1/2] random: use chacha20 for get_random_int/long

ot simpler than otherwise. Finally, on 32-bit platforms where longs and ints are the same size, we simply alias get_random_int to get_random_long. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Suggested-by: Theodore Ts'o <ty...@mit.edu> Cc: Greg Kroah-Hartman <gre...@linuxfou

[PATCH 1/2] random: use chacha20 for get_random_int/long

ot simpler than otherwise. Finally, on 32-bit platforms where longs and ints are the same size, we simply alias get_random_int to get_random_long. Signed-off-by: Jason A. Donenfeld Suggested-by: Theodore Ts'o Cc: Greg Kroah-Hartman Cc: Theodore Ts'o Cc: Hannes Frederic Sowa Cc: Andy

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hey Greg, On Sun, Jan 22, 2017 at 12:24 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Sat, Jan 21, 2017 at 03:08:12PM +0100, Jason A. Donenfeld wrote: >> Hi Ted, >> >> On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o <ty...@mit.edu> wrote: &g

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hey Greg, On Sun, Jan 22, 2017 at 12:24 PM, Greg Kroah-Hartman wrote: > On Sat, Jan 21, 2017 at 03:08:12PM +0100, Jason A. Donenfeld wrote: >> Hi Ted, >> >> On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote: >> > Oh, I see. >> > >> > So

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote: > Oh, I see. > > So that's not how I would do things, but it's fine. Great, alright. In what tree should I look for these two commits? Or should I send it to the drivers/char maintainer (now CCd)? Jason

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Sat, Jan 21, 2017 at 7:24 AM, Theodore Ts'o wrote: > Oh, I see. > > So that's not how I would do things, but it's fine. Great, alright. In what tree should I look for these two commits? Or should I send it to the drivers/char maintainer (now CCd)? Jason

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote: > But there is a shared pointer, which is used both for the dedicated > u32 array and the dedicated u64 array. So when you increment the > pointer for the get_random_u32, the corresponding entry in the u64 > array is wasted,

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote: > But there is a shared pointer, which is used both for the dedicated > u32 array and the dedicated u64 array. So when you increment the > pointer for the get_random_u32, the corresponding entry in the u64 > array is wasted, no? No, it is

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Sat, Jan 21, 2017 at 1:10 AM, Theodore Ts'o wrote: > Why would there be an unaligned access? What I was suggesting was an > array of u32, and we just do two separate u32 accesses with a shift in > the case of get_random_u64. There's nothing illegal about that. > >

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Sat, Jan 21, 2017 at 1:10 AM, Theodore Ts'o wrote: > Why would there be an unaligned access? What I was suggesting was an > array of u32, and we just do two separate u32 accesses with a shift in > the case of get_random_u64. There's nothing illegal about that. > > u64 retval; >

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Fri, Jan 20, 2017 at 3:28 PM, Theodore Ts'o wrote: > Compare that to the fact that you're wasting up to 66% of the > generated words in the batched entropy array, and certainly on average > you're wasting CPU cycles, even if you are reducing the cost of > calling

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Fri, Jan 20, 2017 at 3:28 PM, Theodore Ts'o wrote: > Compare that to the fact that you're wasting up to 66% of the > generated words in the batched entropy array, and certainly on average > you're wasting CPU cycles, even if you are reducing the cost of > calling get_random_u{32,64} by a

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Fri, Jan 20, 2017 at 3:28 PM, Theodore Ts'o wrote: > What I would probably do is just use one array and one array index, > denominated in 32-bit words, and just grab two 32-bit words for the > 64-bit case. Optimizing away the overhead of assembling two 32-bit > words

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Fri, Jan 20, 2017 at 3:28 PM, Theodore Ts'o wrote: > What I would probably do is just use one array and one array index, > denominated in 32-bit words, and just grab two 32-bit words for the > 64-bit case. Optimizing away the overhead of assembling two 32-bit > words for a 64-bit

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Wed, Jan 18, 2017 at 4:49 AM, Theodore Ts'o wrote: > You're using a union for the entropy_u64 and entropy_u32 arrays, and > the position field is used to indexed into those two arrays. > > So if the first caller calls get_random_u64 with position=0, it will > get the

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

Hi Ted, On Wed, Jan 18, 2017 at 4:49 AM, Theodore Ts'o wrote: > You're using a union for the entropy_u64 and entropy_u32 arrays, and > the position field is used to indexed into those two arrays. > > So if the first caller calls get_random_u64 with position=0, it will > get the first 64 bits out

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

FYI, LEDE/OpenWRT is shipping this patchset now: https://github.com/lede-project/source/commit/1708644f1915eb7587a904d81da0ef0b559d1567

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

FYI, LEDE/OpenWRT is shipping this patchset now: https://github.com/lede-project/source/commit/1708644f1915eb7587a904d81da0ef0b559d1567

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

On Sun, Jan 15, 2017 at 3:11 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > According to Ralf, it's queued up for 4.11? Is that right? It's in -next: Part 1: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=fe8bd18ffea5327344d4ec2bf11f47951212abd0 Part

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

On Sun, Jan 15, 2017 at 3:11 PM, Jason A. Donenfeld wrote: > According to Ralf, it's queued up for 4.11? Is that right? It's in -next: Part 1: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=fe8bd18ffea5327344d4ec2bf11f47951212abd0 Part 2: https://git.kernel.

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Hi Greg, On Sun, Jan 15, 2017 at 2:48 PM, Greg Kroah-Hartman wrote: > How many patches is the irqstacks "feature" for MIPS? What kernel was > it released in? Have any git commit ids I can look at? According to Ralf, it's queued up for 4.11? Is that right? Part 1:

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Hi Greg, On Sun, Jan 15, 2017 at 2:48 PM, Greg Kroah-Hartman wrote: > How many patches is the irqstacks "feature" for MIPS? What kernel was > it released in? Have any git commit ids I can look at? According to Ralf, it's queued up for 4.11? Is that right? Part 1:

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Hi James, On Fri, Jan 13, 2017 at 10:49 AM, James Hogan wrote: > Its quite a significant change/feature, especially in terms of potential > for further breakage. I don't think its really stable material to be > honest. It sounds bad if the kernel stack requirement can be

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Hi James, On Fri, Jan 13, 2017 at 10:49 AM, James Hogan wrote: > Its quite a significant change/feature, especially in terms of potential > for further breakage. I don't think its really stable material to be > honest. It sounds bad if the kernel stack requirement can be made > arbitrarily

Re: [PATCH net-next 1/4] siphash: add cryptographically secure PRF

On Thu, Jan 12, 2017 at 4:04 PM, Herbert Xu wrote: >> typedef struct { >>u64 v[2]; >> } siphash_key_t; > > If it's just an 128-bit value then we have u128 in crypto/b128ops.h > that could be generalised for this. Nope, it's actually two 64-bit values. Yes,

Re: [PATCH net-next 1/4] siphash: add cryptographically secure PRF

On Thu, Jan 12, 2017 at 4:04 PM, Herbert Xu wrote: >> typedef struct { >>u64 v[2]; >> } siphash_key_t; > > If it's just an 128-bit value then we have u128 in crypto/b128ops.h > that could be generalised for this. Nope, it's actually two 64-bit values. Yes, the user fills it in as one

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

On Wed, Jan 11, 2017 at 2:20 AM, Ralf Baechle <r...@linux-mips.org> wrote: > On Wed, Jan 11, 2017 at 12:32:38AM +0100, Jason A. Donenfeld wrote: > >> Was this ever picked up for 4.10 or 4.11? > > Still sitting in -next as commit 3cc3434fd630 and its four parent com

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

On Wed, Jan 11, 2017 at 2:20 AM, Ralf Baechle wrote: > On Wed, Jan 11, 2017 at 12:32:38AM +0100, Jason A. Donenfeld wrote: > >> Was this ever picked up for 4.10 or 4.11? > > Still sitting in -next as commit 3cc3434fd630 and its four parent commits. Oh, good, so it's progressin

Re: [PATCH v2] drivers: char: mem: Fix thinkos in kmem address checks

Tested-by: Jason A. Donenfeld <ja...@zx2c4.com> My extract-keys [1] utility works again: $ sudo ./extract-keys wg0 0x08d3c7a3 IbbC5O9g2dTZBeLQoivmKZtdSGqufU+M2s2oaFzMfYA= 0xdf917af6 3cUm2mXNaZVzWDmJIZ9XlPpvJ63GH1uyUwKLN1g1Dhs= [1] https://git.zx2c4.com/WireGuard/tree/contrib/examples/e

Re: [PATCH v2] drivers: char: mem: Fix thinkos in kmem address checks

Tested-by: Jason A. Donenfeld My extract-keys [1] utility works again: $ sudo ./extract-keys wg0 0x08d3c7a3 IbbC5O9g2dTZBeLQoivmKZtdSGqufU+M2s2oaFzMfYA= 0xdf917af6 3cUm2mXNaZVzWDmJIZ9XlPpvJ63GH1uyUwKLN1g1Dhs= [1] https://git.zx2c4.com/WireGuard/tree/contrib/examples/extract-keys

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Was this ever picked up for 4.10 or 4.11?

Re: [PATCH v3 0/5] MIPS: Add per-cpu IRQ stack

Was this ever picked up for 4.10 or 4.11?

[RFC] Use of SipHash and HalfSipHash for Hashtables and PRF

Hi all, In this case, by "RFC" I actually mean "request for commits". No comments, please. :) David Miller's net-next tree now has my SipHash patchset, which adds SipHash to the kernel for all sorts of interesting uses. The first two uses include syncookies and secure sequence numbers. Future

[RFC] Use of SipHash and HalfSipHash for Hashtables and PRF

Hi all, In this case, by "RFC" I actually mean "request for commits". No comments, please. :) David Miller's net-next tree now has my SipHash patchset, which adds SipHash to the kernel for all sorts of interesting uses. The first two uses include syncookies and secure sequence numbers. Future

[PATCH v2] ext4: move halfmd4 into hash.c directly

, and make it just a local function in ext4's hash.c. There's precedent for doing this; the other function ext can use for its hashes -- TEA -- is also implemented in the same place. Also, by being a local function, this might allow gcc to perform some additional optimizations. Signed-off

[PATCH v2] ext4: move halfmd4 into hash.c directly

, and make it just a local function in ext4's hash.c. There's precedent for doing this; the other function ext can use for its hashes -- TEA -- is also implemented in the same place. Also, by being a local function, this might allow gcc to perform some additional optimizations. Signed-off

[PATCH v3 net-next 2/4] siphash: implement HalfSipHash1-3 for hash tables

slower than jhash(), but comes with a considerable security improvement. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> --- Documentation/siphash.txt | 75 +++ include/linux/siphash.h | 57 +

[PATCH v3 net-next 2/4] siphash: implement HalfSipHash1-3 for hash tables

slower than jhash(), but comes with a considerable security improvement. Signed-off-by: Jason A. Donenfeld Reviewed-by: Jean-Philippe Aumasson --- Documentation/siphash.txt | 75 +++ include/linux/siphash.h | 57 +++- lib/siphash.c

[PATCH v3 net-next 3/4] secure_seq: use SipHash in place of MD5

] secure_tcp_sequence_number_siphash# cycles: 86015473 Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Andi Kleen <a...@linux.intel.com> Cc: David Miller <da...@davemloft.net> Cc: David Laight <david.lai...@aculab.com> Cc: Tom Herbert <t...@herbertland.com> Cc: Hannes Frederic Sowa <han

[PATCH v3 net-next 4/4] syncookies: use SipHash in place of SHA1

. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Eric Dumazet <eric.duma...@gmail.com> Cc: David Miller <da...@davemloft.net> --- net/ipv4/syncookies.c | 21 + net/ipv6/syncookies.c | 41 +++-- 2 files changed, 24

[PATCH v3 net-next 3/4] secure_seq: use SipHash in place of MD5

] secure_tcp_sequence_number_siphash# cycles: 86015473 Signed-off-by: Jason A. Donenfeld Cc: Andi Kleen Cc: David Miller Cc: David Laight Cc: Tom Herbert Cc: Hannes Frederic Sowa Cc: Eric Dumazet --- net/core/secure_seq.c | 145 ++ 1 file changed, 63 insertions(+), 82

[PATCH v3 net-next 4/4] syncookies: use SipHash in place of SHA1

. Signed-off-by: Jason A. Donenfeld Cc: Eric Dumazet Cc: David Miller --- net/ipv4/syncookies.c | 21 + net/ipv6/syncookies.c | 41 +++-- 2 files changed, 24 insertions(+), 38 deletions(-) diff --git a/net/ipv4/syncookies.c b/net/ipv4

[PATCH v3 net-next 0/4] Introduce The SipHash PRF

ing. - A typo in the documentation has been fixed. - The documentation has been augmented with an example relating to struct packing and passing. - The net_secret variable is now __read_mostly. Hopefully this is the last of the required revisions, and v3 can be merged into net-next. Ja

[PATCH v3 net-next 1/4] siphash: add cryptographically secure PRF

s. SipHash is a widely known high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> Cc: Linus Torvalds <torva...@linux-foundation.org&

[PATCH v3 net-next 0/4] Introduce The SipHash PRF

ing. - A typo in the documentation has been fixed. - The documentation has been augmented with an example relating to struct packing and passing. - The net_secret variable is now __read_mostly. Hopefully this is the last of the required revisions, and v3 can be merged into net-next. Ja

[PATCH v3 net-next 1/4] siphash: add cryptographically secure PRF

s. SipHash is a widely known high-speed solution to a widely known set of problems, and it's time we catch-up. Signed-off-by: Jason A. Donenfeld Reviewed-by: Jean-Philippe Aumasson Cc: Linus Torvalds Cc: Eric Biggers Cc: David Laight Cc: Eric Dumazet --- Documentation/siphash

Re: [PATCH v2 net-next 0/4] Introduce The SipHash PRF

Hi Eric, Thanks for round two. I'll address these. Comments are inline below. On Sat, Jan 7, 2017 at 8:54 PM, Eric Biggers wrote: > Hi Jason, thanks for doing this! Yes, I had gotten a little lost in the > earlier > discussions about the 'random' driver and other

Re: [PATCH v2 net-next 0/4] Introduce The SipHash PRF

Hi Eric, Thanks for round two. I'll address these. Comments are inline below. On Sat, Jan 7, 2017 at 8:54 PM, Eric Biggers wrote: > Hi Jason, thanks for doing this! Yes, I had gotten a little lost in the > earlier > discussions about the 'random' driver and other potential users of SipHash.

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

Hi David, On Sat, Jan 7, 2017 at 10:37 PM, David Miller wrote: > This and the next patch are a real shame, performance wise, on cpus > that have single-instruction SHA1 and MD5 implementations. Sparc64 > has both, and I believe x86_64 can do SHA1 these days. > > It took so

Re: [PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

Hi David, On Sat, Jan 7, 2017 at 10:37 PM, David Miller wrote: > This and the next patch are a real shame, performance wise, on cpus > that have single-instruction SHA1 and MD5 implementations. Sparc64 > has both, and I believe x86_64 can do SHA1 these days. > > It took so long to get those

[PATCH v2 net-next 4/4] syncookies: use SipHash in place of SHA1

. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Eric Dumazet <eric.duma...@gmail.com> Cc: David Miller <da...@davemloft.net> --- net/ipv4/syncookies.c | 21 + net/ipv6/syncookies.c | 41 +++-- 2 files changed, 24

[PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

] secure_tcp_sequence_number_siphash# cycles: 86015473 Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Andi Kleen <a...@linux.intel.com> Cc: David Miller <da...@davemloft.net> Cc: David Laight <david.lai...@aculab.com> Cc: Tom Herbert <t...@herbertland.com> Cc: Hannes Frederic Sowa <han

[PATCH v2 net-next 3/4] secure_seq: use SipHash in place of MD5

] secure_tcp_sequence_number_siphash# cycles: 86015473 Signed-off-by: Jason A. Donenfeld Cc: Andi Kleen Cc: David Miller Cc: David Laight Cc: Tom Herbert Cc: Hannes Frederic Sowa Cc: Eric Dumazet --- net/core/secure_seq.c | 145 ++ 1 file changed, 63 insertions(+), 82

[PATCH v2 net-next 4/4] syncookies: use SipHash in place of SHA1

. Signed-off-by: Jason A. Donenfeld Cc: Eric Dumazet Cc: David Miller --- net/ipv4/syncookies.c | 21 + net/ipv6/syncookies.c | 41 +++-- 2 files changed, 24 insertions(+), 38 deletions(-) diff --git a/net/ipv4/syncookies.c b/net/ipv4

[PATCH v2 net-next 2/4] siphash: implement HalfSipHash1-3 for hash tables

slower than jhash(), but comes with a considerable security improvement. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumas...@gmail.com> --- Documentation/siphash.txt | 75 +++ include/linux/siphash.h | 62 ++

[PATCH v2 net-next 2/4] siphash: implement HalfSipHash1-3 for hash tables

slower than jhash(), but comes with a considerable security improvement. Signed-off-by: Jason A. Donenfeld Reviewed-by: Jean-Philippe Aumasson --- Documentation/siphash.txt | 75 +++ include/linux/siphash.h | 62 - lib/siphash.c

<    5   6   7   8   9   10   11   12   13   14   >