Re: [PATCH v7 0/5] skb_to_sgvec hardening

On Tue, May 9, 2017 at 4:03 PM, Johannes Berg wrote: > Perhaps you should add __must_check annotation to the function > prototype(s)? Great idea. I've started doing this in my own code. Wasn't sure how popular it was outside of there, but I'm glad to hear a suggestion of it now. I'll have this in

[PATCH v7 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Cc: David Howells --- net/rxrpc/rxkad.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..486026689448 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7

[PATCH v7 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Cc: Sabrina Dubroca --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index 49ce4e9f4a0f..e022e3fcd012 100644 --- a/drivers/net/macsec.c +++ b/drivers/net

[PATCH v7 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Cc: Steffen Klassert Cc: Herbert Xu Cc: "David S. Miller" --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 30 -- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 31 +-- 4 files c

[PATCH v7 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Cc: "Michael S. Tsirkin" Cc: Jason Wang --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/d

[PATCH v7 0/5] skb_to_sgvec hardening

h an error: 1) When the passed in sglist is too small; and 2) When the passed in skbuff is too deeply nested. So, the first patch in this series handles the issues with skb_to_sgvec directly, and the remaining ones then handle the call sites. Jason A. Donenfeld (5): skbuff: return -E

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

rted the recent MIPS changes that give it a separate IRQ stack, so that I could experience some worst-case situations. I found that limiting it to 24 layers deep yielded a good stack usage with room for safety, as well as being much deeper than any driver actually ever creates. Signed-off-by: Ja

Re: crypto_memneq not backported to 3.10

Hey Willy, On Sun, Apr 9, 2017 at 3:25 PM, Willy Tarreau wrote: > > Hi Jason, > > On Sun, Apr 09, 2017 at 02:59:53PM +0200, Jason A. Donenfeld wrote: > > Hey Willy, > > > > Linux 3.10 is inexplicably missing crypto_memneq, making all crypto > > mac compariso

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

Hi Sabrina, On Fri, Apr 28, 2017 at 6:18 PM, Sabrina Dubroca wrote: > One small thing here: since you're touching this comment, could you > move it next to skb_to_sgvec, since that's the function it's supposed > to document? Done. I'll wait until next week to resubmit, to give some more time for

Re: [PATCH v6 3/5] rxrpc: check return value of skb_to_sgvec always

Hi Sabrina, Thanks for the review. On Fri, Apr 28, 2017 at 1:41 PM, Sabrina Dubroca wrote: > > sg_init_table(sg, nsg); > > - skb_to_sgvec(skb, sg, offset, len); > > + if (unlikely(skb_to_sgvec(skb, sg, offset, len) < 0)) > > + goto nomem; > > You're leaking sg when nsg

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

On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca wrote: > Hmm, I think this can actually happen: Alright, perhaps better to err on the side of caution, then. Jason

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

Hey Dave, David Laight and I have been discussing offlist. It occurred to both of us that this could just be turned into a loop because perhaps this is actually just tail-recursive. Upon further inspection, however, the way the current algorithm works, it's possible that each of the fraglist skbs

[PATCH v6 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/rxrpc/rxkad.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..dcf46c9c3ece 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9 @@ static int

[PATCH v6 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 30 -- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 31 +-- 4 files changed, 53 insertions(+), 24 deletions(-) diff --git a/net/ipv4/ah4.c b/net

[PATCH v6 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c

[PATCH v6 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index dbab05afcdbe..d846f42b99ec 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -733,7

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

an easily avoid here. Signed-off-by: Jason A. Donenfeld --- Changes v5->v6: * Use unlikely() for the rare overflow conditions. * Also bound recursion, since this is a potential disaster we can avert. net/core/skbuff.c | 31 --- 1 file changed, 24 insertio

[PATCH v2] macsec: dynamically allocate space for sglist

We call skb_cow_data, which is good anyway to ensure we can actually modify the skb as such (another error from prior). Now that we have the number of fragments required, we can safely allocate exactly that amount of memory. Signed-off-by: Jason A. Donenfeld Cc: Sabrina Dubroca Cc: secur

[PATCH v5 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/rxrpc/rxkad.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..dcf46c9c3ece 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9 @@ static int

[PATCH v5 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index dbab05afcdbe..d846f42b99ec 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -733,7

[PATCH v5 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c

[PATCH v5 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 30 -- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 31 +-- 4 files changed, 53 insertions(+), 24 deletions(-) diff --git a/net/ipv4/ah4.c b/net

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

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec") Signed-off-by: Jason A. Donenfeld --- This is a resend of v4 with all the other child commits along with it. net/core/skbuff.c | 12 +++- 1 file c

[PATCH] macsec: dynamically allocate space for sglist

We call skb_cow_data, which is good anyway to ensure we can actually modify the skb as such (another error from prior). Now that we have the number of fragments required, we can safely allocate exactly that amount of memory. Signed-off-by: Jason A. Donenfeld Cc: Sabrina Dubroca Cc: secur

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

On Tue, Apr 25, 2017 at 5:12 PM, Sabrina Dubroca wrote: >> https://patchwork.ozlabs.org/patch/754861/ > > Yes, that prevents the overflow, but now you're just dropping > packets. Right, it's a so-called "defense-in-depth" measure. > I'll review that later, let's fix the overflow without > breaki

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

Hi Sabrina, On Tue, Apr 25, 2017 at 4:53 PM, Sabrina Dubroca wrote: > Ugh, good catch :/ > > AFAICT this patch doesn't really help, because NETIF_F_FRAGLIST > doesn't get tested in paths that can lead to triggering this. You're right. This fixes the xmit() path, but not the receive path, which a

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

This is a defense-in-depth measure in response to bugs like 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec") Signed-off-by: Jason A. Donenfeld --- v4 fixes the commit message and moves the check into the inner-most if. net/core/skbuff.c | 12 +++- 1 file c

[PATCH v3 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 --- Sorry for the completely stupid amount of churn - v1,v2,v3 in the span of two minutes. It's just that after noticing first that nsg needs to be check

[PATCH v2 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 | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index

[PATCH 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index dbab05afcdbe..d846f42b99ec 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -733,7

[PATCH 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 30 -- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 31 +-- 4 files changed, 53 insertions(+), 24 deletions(-) diff --git a/net/ipv4/ah4.c b/net

[PATCH 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- net/rxrpc/rxkad.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 4374e7b9c7bf..dcf46c9c3ece 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -229,7 +229,9 @@ static int

[PATCH 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld --- drivers/net/virtio_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index f36584616e7d..1709fd0b4bf7 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c

[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 one of those operations th

[PATCH] macsec: avoid heap overflow in skb_to_sgvec

ually, but not if you're using NETIF_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

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 bec

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 c

[PATCH] padata: allow caller to control queue length

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 Reported-by: Dan Carpenter --- kernel/padata.c | 13 - 1 file changed, 4 insertions(+), 9 dele

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 fol

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

7;s Ted's and Greg's 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 repla

[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

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

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 deb

[PATCH] padata: avoid race in reordering

call to list_entry is not locked, which means it's feasible that two threads pick up the same padata object 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 +++

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,

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 here:

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 fi

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

since 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. W

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 networking, because it doe

[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/ra

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

assembly this generates is a lot 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

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. >> > >> &g

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, no? No, it is not

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 get_random_u{32,64} by a handfu

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 word

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

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://g

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: https://lkml.org/lkml/2016/12

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 large

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 blob

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 progr

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?

[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 use

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

d lib, 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

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

imes 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 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

#x27;s happening. - 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

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

in their kernels. 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 --- D

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. I

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 inst

[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

imes 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

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

in their kernels. 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 --- D

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

n casts. - White space fixups. - Word wrapping fixes. - The valid suggestions from checkpatch. Jason A. Donenfeld (4): siphash: add cryptographically secure PRF siphash: implement HalfSipHash1-3 for hash tables secure_seq: use SipHash in place of MD5 syncookies: use SipHas

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

Hi Eric, Thanks for the review. I wish we had gotten to this much earlier before the merge, when there were quite a few revisions and refinements, but better late than never, and I'm quite pleased to have your feedback for making this patchset perfect. Comments are inline below. On Sat, Jan 7, 20

[PATCH 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 | 20 net/ipv6/syncookies.c | 37 - 2 files changed, 20 insertions(+), 37 deletions(-) diff --git a/net/ipv4/syncookies.c b/net/ipv4

[PATCH 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 | 135 -- 1 file changed, 54 insertions(+), 81

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

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

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

in their kernels. 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 Cc: Jean-Philippe Aumasson Cc: Linus Torvalds Cc: Eric Biggers Cc: David Laight Cc: Eric Dumazet --- D

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

on, the initial import of these functions is coming through the networking tree. After these are merged, it will then be easier to expand use elsewhere. Jason A. Donenfeld (4): siphash: add cryptographically secure PRF siphash: implement HalfSipHash1-3 for hash tables secure_seq: use SipHash

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

Will resubmit. Sorry. I had this in earlier series and dropped it in this one. Apologies. Give me 30 minutes and you'll have a beautiful and conformant patch series.

[PATCH 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 | 20 net/ipv6/syncookies.c | 37 - 2 files changed, 20 insertions(+), 37 deletions(-) diff --git a/net/ipv4/syncookies.c b/net/ipv4

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

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

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

in their kernels. 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 Cc: Jean-Philippe Aumasson Cc: Linus Torvalds Cc: Eric Biggers Cc: David Laight Cc: Eric Dumazet --- D

[PATCH 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 | 135 -- 1 file changed, 54 insertions(+), 81

[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: Theodore Ts'o --- drivers/char/random.c | 55 +- include/linux/random.h | 17 ++

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

assembly this generates is a lot 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: Theodore Ts'o Cc: Hannes Frederic Sowa Cc:

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

d lib, 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

[PATCH] Revert "drivers: char: mem: Check {read,write}_kmem() addresses"

sizeof(addr)) { perror("read"); return errno; } printf("It worked, reading the value %lx!\n", addr); close(fd); close(sock); return 0; } Signed-off-by: Jason A. Donenfeld Cc: Robin Murphy Cc: Kefeng Wa

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