checksumming on non-local forward path

Hey netdev, In a protocol like wireguard, if a packet arrives on the other end of the tunnel, and the crypto checks out, then we're absolutely certain that the packet hasn't been modified in transit. In this case, there's no useful information that validating the inner checksums of the various

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

On Fri, Sep 28, 2018 at 12:37 AM Jason A. Donenfeld wrote: > Will do. v7 will include the wg_ prefix. $ nm *.o | while read a b c; do [[ $b == T ]] && echo $c; done | grep -v ^wg_ cleanup_module init_module Success.

Re: [PATCH net-next v6 23/23] net: WireGuard secure network tunnel

Hi Andrew, Thanks for following up with this. On Thu, Sep 27, 2018 at 3:15 AM Andrew Lunn wrote: > I know you have been concentrating on the crypto code, so i'm not > expecting too many changes at the moment in the network code. I should be addressing things in parallel, actually, so I'm happy

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

Hi Eric, On Thu, Sep 27, 2018 at 8:29 PM Eric Biggers wrote: > Why is Herbert Xu's existing crypto tree being circumvented, especially for > future patches (the initial merge isn't quite as important as that's a > one-time > event)? I like being able to check out cryptodev to test upcoming

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Thu, Sep 27, 2018 at 6:27 PM Andy Lutomirski wrote: > I would add another consideration: if you can get better latency with > negligible overhead (0.1%? 0.05%), then that might make sense too. For > example, it seems plausible that checking need_resched() every few blocks > adds basically

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hey again Thomas, On Thu, Sep 27, 2018 at 3:26 PM Jason A. Donenfeld wrote: > > Hi Thomas, > > I'm trying to optimize this for crypto performance while still taking > into account preemption concerns. I'm having a bit of trouble figuring > out a way to determine numerically wha

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

Hi Thomas, I'm trying to optimize this for crypto performance while still taking into account preemption concerns. I'm having a bit of trouble figuring out a way to determine numerically what the upper bounds for this stuff looks like. I'm sure I could pick a pretty sane number that's arguably

[PATCH net-next v6 17/23] zinc: Curve25519 generic C implementations and selftest

*: https://github.com/project-everest/hacl-star The 32-bit version comes from Fiat: https://github.com/mit-plv/fiat-crypto Information: https://cr.yp.to/ecdh.html Signed-off-by: Jason A. Donenfeld Cc: Samuel Neves Cc: Andy Lutomirski Cc: Greg KH Cc: Jean-Philippe Aumasson Cc: Karthikeyan Bhargavan

[PATCH net-next v5 13/20] zinc: BLAKE2s x86_64 implementation

These implementations from Samuel Neves support AVX and AVX-512VL. Originally this used AVX-512F, but Skylake thermal throttling made AVX-512VL more attractive and possible to do with negligable difference. Signed-off-by: Jason A. Donenfeld Signed-off-by: Samuel Neves Cc: Andy Lutomirski Cc

Re: [PATCH net-next v4 18/20] crypto: port ChaCha20 to Zinc

Hey Martin, Thanks for running these and pointing this out. I've replicated the results with tcrypt and fixed some issues, and the next patch series should be a lot closer to what you'd expect, instead of the regression you noticed. Most of the slowdown happened as a result of over-eager XSAVEs,

Re: [PATCH net-next v3 02/17] zinc: introduce minimal cryptography library

Hi Eric, On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote: > I'd strongly prefer the assembly to be readable too. Jason, I'm not sure if > you've actually read through the asm from the OpenSSL implementations, but the > generated .S files actually do lose a lot of semantic information that

Re: [PATCH v1 3/3] net: WireGuard secure network tunnel

On Tue, Aug 21, 2018 at 4:54 PM David Miller wrote: > > From: "Jason A. Donenfeld" > Date: Tue, 21 Aug 2018 16:41:50 -0700 > > > Is 100 in fact acceptable for new code? 120? 180? What's the > > generally accepted limit these days? > > Please keep it as c

Re: [PATCH v1 3/3] net: WireGuard secure network tunnel

On Tue, Jul 31, 2018 at 1:22 PM Stephen Hemminger wrote: > > On Tue, 31 Jul 2018 21:11:02 +0200 > "Jason A. Donenfeld" wrote: > > > +static int walk_by_peer(struct allowedips_node __rcu *top, u8 bits, struct > > allowedips_cursor *cursor, struct wireguard_peer

[PATCH v2] fib_rules: match rules based on suppress_* properties too

Two rules with different values of suppress_prefix or suppress_ifgroup are not the same. This fixes an -EEXIST when running: $ ip -4 rule add table main suppress_prefixlength 0 Signed-off-by: Jason A. Donenfeld Fixes: f9d4b0c1e969 ("fib_rules: move common handling of newrule delrule

[PATCH] fib_rules: match rules based on suppress_* properties too

Two rules with different values of suppress_prefix or suppress_ifgroup are not the same. This fixes an -EEXIST when running: $ ip -4 rule add table main suppress_prefixlength 0 Signed-off-by: Jason A. Donenfeld Fixes: f9d4b0c1e969 ("fib_rules: move common handling of newrule delrule

[net regression] "fib_rules: move common handling of newrule delrule msgs into fib_nl2rule" breaks suppress_prefixlength

Hey Roopa, On a kernel with a minimal networking config, CONFIG_IP_MULTIPLE_TABLES appears to be broken for certain rules after f9d4b0c1e9695e3de7af3768205bacc27312320c. Try, for example, running: $ ip -4 rule add table main suppress_prefixlength 0 It returns with EEXIST. Perhaps the reason

Re: safe skb resetting after decapsulation and encapsulation

On Sat, May 12, 2018 at 4:07 AM, Md. Islam wrote: > I'm not an expert on this, but it looks about right. Really? Even zeroing between headers_start and headers_end? With the latest RHEL 7.5 kernel's i40e driver, doing this results in a crash in kfree. It's possible redhat is

safe skb resetting after decapsulation and encapsulation

Hey Netdev, A UDP skb comes in via the encap_rcv interface. I do a lot of wild things to the bytes in the skb -- change where the head starts, modify a few fragments, decrypt some stuff, trim off some things at the end, etc. In other words, I'm decapsulating the skb in a pretty intense way. I

Re: [PATCH] netlink: put module reference if dump start fails

Thanks! Jason

Re: [PATCH] netlink: put module reference if dump start fails

Fixes: 41c87425a1ac ("netlink: do not set cb_running if dump's start() errs")

Re: [PATCH] netlink: put module reference if dump start fails

On Wed, Feb 21, 2018 at 6:47 AM, Eric Dumazet wrote: >> This probably should be queued up for stable. > > When was the bug added ? This would help a lot stable teams ... This needs to be backported to 4.16-rc0+, 4.15+, 4.14+, 4.13.14+, and 4.9.63+.

[PATCH] netlink: put module reference if dump start fails

ounter back to zero, especially since module.c still uses atomic_inc instead of refcount_inc. This patch expands the error path to simply call module_put if cb->start() fails. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- This probably should be queued up for stable. net/netli

Re: WireGuard Upstreaming Roadmap (November 2017)

Hi Dave, On Fri, Dec 8, 2017 at 4:38 PM, David Miller wrote: > Sorry, you cannot force the discussion of a feature which will be submitted > upstream to occur on a private mailing list. > > It is _ABSOLUTELY_ appropriate to discss this on netdev since it is the > netdev

Re: WireGuard Upstreaming Roadmap (November 2017)

On Thu, Dec 7, 2017 at 11:22 AM, Stefan Tatschner wrote: > I have a question which is related to the involved crypto. As far as I > have understood the protocol and the concept of wireguard > What's your opinion on this? This thread has been picked up on the WireGuard

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Sat, Nov 11, 2017 at 11:18 PM, Johannes Berg wrote: > >> > If you're handling this by forcing another read() to procude the >> > NLMSG_DONE, then you have no reason to WARN_ON() here. >> > >> > In fact you are adding a WARN_ON() which is trivially triggerable by >> >

WireGuard Upstreaming Roadmap (November 2017)

Hi folks, This relates to WireGuard [0]. Following a very nice conference with the Linux kernel networking subsystem community [1,2], I thought it might be a good idea to spell out the roadmap for the coming months and the trajectory into upstream, based on my discussions with several developers

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Sat, Nov 11, 2017 at 11:37 AM, David Miller wrote: > Jason I'm already pushing my luck as-is with the pull request I made > yesterday. > > I've seen your original requst to get this in, you don't have to say > it multiple times. > > We can get this into the merge window

Re: [PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

IIRC, 4.14 comes tomorrow-ish? If possible, it would be nice to get this in 4.14 before then, so it doesn't have to take time to trickle down through stable. Jason On Thu, Nov 9, 2017 at 1:04 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > The way people generally use net

[PATCH v4] af_netlink: ensure that NLMSG_DONE never fails in dumps

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Can we get this into 4.14? Is there still time? It should also be queued up for stable. Changes v3->v4: - I like long lines. The kernel does not. Wrapp

Re: [PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

On Thu, Nov 9, 2017 at 11:02 AM, Johannes Berg wrote: > nit: I think your line got a little long here :) Ack. For v4. > and here Ack. For v4. > >> + nlk->dump_done_errno = INT_MAX; > > I guess positive values aren't really returned from dump? When a positive

[PATCH v3] af_netlink: ensure that NLMSG_DONE never fails in dumps

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Can we get this into 4.14? Is there still time? It should also be queued up for stable. Changes v2->v3: - Johannes didn't like the subject line of t

[PATCH v2] af_netlink: give correct bounds to dump skb for NLMSG_DONE

to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Changes v1->v2: - This implements things without having to twiddle with the skb, at the expense of potentially having an extra back-and-forth and qui

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

Erf, your patch doesn't handle what happens if len comes back negative, but I'll fix it up and send a v2 using this approach. I think I really prefer v1 though. Jason

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

Hi Johannes, Yes indeed. It sacrifices 24 bytes for making things much less complex. However, if you prefer increasing the complexity of the state machine a bit instead, I suppose we could roll with this approach instead... Jason

Re: [PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

By the way, in case you're curious, here's the {up,down,cross}stream WireGuard commit that works around it via its compat layer (a rat's nest of hideous backports for all the weird kernels people want WireGuard to run on, which I cannot wait to remove):

[PATCH] af_netlink: give correct bounds to dump skb for NLMSG_DONE

-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- See you all at netdevconf tomorrow! net/netlink/af_netlink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c index b93148e8e9fb..b2d0a2fb1939 100644 --- a/net/netlink/af_netlink.c +++

Re: [PATCH net] tun/tap: sanitize TUNSETSNDBUF input

Here's a simple reproducer, in case Skyzaller's case was overcomplicated: #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct ifreq ifr; int fd, sock; fd = open("/dev/net/tun", O_RDWR); if (fd < 0) {

[PATCH] mac80211: use constant time comparison with keys

Otherwise we risk leaking information via timing side channel. Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything") Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/mac80211/key.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: pull-request: mac80211 2017-10-16

On Tue, Oct 17, 2017 at 7:46 AM, Johannes Berg wrote: > If it's not equal, you execute so much code > beneath, going to the driver etc., that I'd think this particular time > is in the noise. Usually presumptions like this get you in trouble when some crafty academic

Re: pull-request: mac80211 2017-10-16

Mobile phone right now, so not able to write patch, but you probably should be using crypto_memneq for comparing those two keys, not memcmp. 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.

[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

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

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

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

Re: cross namespace interface notification for tun devices

On Mon, Oct 2, 2017 at 11:32 AM, Nicolas Dichtel wrote: > 1. Move the process to netns B, open the netlink socket and move back the > process to netns A. The socket will remain in netns B and you will receive all > netlink messages related to netns B. > > 2. Assign a

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

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

[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

Re: cross namespace interface notification for tun devices

On Wed, Sep 20, 2017 at 8:29 PM, Cong Wang wrote: > Sounds like we should set NETIF_F_NETNS_LOCAL for tun > device. Absolutely do not do this under any circumstances. This would be a regression and would break API compatibility. As I wrote in my first email, it's

Re: cross namespace interface notification for tun devices

On Tue, Sep 19, 2017 at 10:40 PM, Cong Wang wrote: > By "notification" I assume you mean netlink notification. Yes, netlink notification. > The question is why does the process in A still care about > the device sitting in B? > > Also, the process should be able to

Re: cross namespace interface notification for tun devices

On Mon, Sep 18, 2017 at 8:47 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > The best I've come up with is, in a sleep loop, writing to the tun > device's fd something with a NULL or invalid payload. If the interface > is down, the kernel returns -EIO. If the interface is

cross namespace interface notification for tun devices

Hey guys, It's possible to create a tun device in a process in namespace A and then move that interface to namespace B. The controlling process in A needs to receive notifications on when the interface is brought up or down. It can receive these notifications via netlink while the interface lives

[PATCH] ioc3-eth: store pointer to net_device for priviate area

in [1]. [1] http://www.spinics.net/lists/netdev/msg443992.html Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Ralf - I don't have the platform to test this out, so you might want to briefly put it through the paces before giving it your sign-off. drivers/net/ethernet/sgi/ioc3-eth.

Re: [PATCH 1/2] netdevice: add netdev_pub helper function

On Mon, Jul 10, 2017 at 10:04 AM, David Miller wrote: > I disagree. Assuming one can go from the driver private to the netdev > object trivially is a worse assumption than the other way around, and > locks us into the current implementation of how the netdev and driver >

[PATCH 2/2] ioc3-eth: use netdev_pub instead of handrolling alignment

It's safer to use the generic library function for this, rather than reinventing it here with hard-coded alignment values. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/net/ethernet/sgi/ioc3-eth.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff

[PATCH 1/2] netdevice: add netdev_pub helper function

single function, which makes everything confusing and less clear. Additionally, this enables a "correct" way of doing such a thing, instead of having drivers attempt to reinvent the wheel and screw it up. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- include/linux/

Re: net: Fix inconsistent teardown and release of private netdev state.

On Sat, Jul 8, 2017 at 12:39 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Thu, Jul 6, 2017 at 7:24 AM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: >> list_add(>list, _of_things); >> >> ret = register_netdevice(); // if ret is < 0, t

Re: net: Fix inconsistent teardown and release of private netdev state.

On Thu, Jul 6, 2017 at 4:24 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > if (!ret) > pr_info("Yay it worked!\n"); > > return 0; This is supposed to be `return ret;`. See, even in psuedocode it's hard to get right.

Re: net: Fix inconsistent teardown and release of private netdev state.

Hey guys, I see why this priv_destructor patch is an acceptable bandaid for certain drivers, but I'm not exactly sure on the cleanest way of using it in new drivers. Check out the following psuedocode. Here's how error handling in newlink used to work before this patch: static void

Re: [PATCH] net/icmp: restore source address if packet is NATed

Hi David, On Sun, Jun 25, 2017 at 5:49 PM, David Miller wrote: > This violates things on so many levels. Yes, indeed. > I think this kind of thing need to be hidden inside of netfilter, > it can do the rate limiting and stuff like that in the spot > where it makes the

[PATCH] net/icmp: restore source address if packet is NATed

of the subsequent processing in the icmp_send and icmpv6_send functions, so we do the lookup very early on, so that the rest of the ICMP machinery can progress as usual. In my tests, this setup works very well. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- net/ipv4/icmp.

Re: [PATCH 0/6] Constant Time Memory Comparisons Are Important

Hi Stephan, On Sun, Jun 11, 2017 at 11:06 PM, Stephan Müller wrote: > Are you planning to send an update to your patch set? If yes, there is another > one which should be converted too: crypto/rsa-pkcs1pad.c. I just sent an update to this thread patching that, per your

[PATCH 0/6] Constant Time Memory Comparisons Are Important

cleaning this stuff up. The following 6 locations were found with some simple regex greps, but I'm sure more lurk below the surface. If you maintain some code or know somebody who maintains some code that deals with MACs, tell them to double check which comparison function they're using. Jason

[PATCH 2/6] net/ipv6: use constant time memory comparison for mac

Otherwise, we enable a MAC forgery via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "David S. Miller" <da...@davemloft.net> Cc: netdev@vger.kernel.org Cc: sta...@vger.kernel.org --- net/ipv6/seg6_hmac.c | 3 ++- 1 file changed, 2 insertions(+), 1 d

[PATCH net-next v10 0/5] Avoiding stack overflow in skb_to_sgvec

all; 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 -EMSGSIZE in skb_to_sgvec to prevent overflow ipsec: check ret

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

ecent 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: Jason A. Don

[PATCH net-next v10 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Acked-by: David Howells <dhowe...@redhat.com> --- net/rxrpc/rxkad.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 1bb9b2ccc267..29fe20ad04aa 1006

[PATCH net-next v10 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Steffen Klassert <steffen.klass...@secunet.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: "David S. Miller" <da...@davemloft.net> --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 20

[PATCH net-next v10 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Sabrina Dubroca <s...@queasysnail.net> --- 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 91642fd87cd1..b79513b

[PATCH net-next v10 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> Cc: "Michael S. Tsirkin" <m...@redhat.com> Cc: Jason Wang <jasow...@redhat.com> --- drivers/net/virtio_net.c | 9 +++-- 1 file changed, 7 i

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

On Wed, May 24, 2017 at 6:41 PM, Sergei Shtylyov >I've only looked on the last 2 patches. You can add my: > > Reviewed-by: Sergei Shtylyov > > if you want. :-) Will do. For the series, or just for 5/5?

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

I'm shocked this somehow made it into the commit. I wonder how that happened? Anyway, fixed in my git repo, and will be part of the next series. (Unless DaveM wants to fix it up trivially when/if he merges this v9, which would be faster.) Barring that, does this look good to you? Could I have

Re: [PATCH net-next v9 0/5] skb_to_sgvec hardening

Hi List, Could somebody do a holistic review of the series, or at least on individual commits that seem fine, and sign off on it, so that this can actually be merged? We're now at v9. I hope we can get this merged now, but if not, I'd like for v10 to finally land these changes. Regards, Jason

[PATCH net-next v9 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Steffen Klassert <steffen.klass...@secunet.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: "David S. Miller" <da...@davemloft.net> --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 20

[PATCH net-next v9 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Sabrina Dubroca <s...@queasysnail.net> --- 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 cdc347be68f2..dfcb1e9

[PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "Michael S. Tsirkin" <m...@redhat.com> Cc: Jason Wang <jasow...@redhat.com> --- drivers/net/virtio_net.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/virtio_net.c b/dr

[PATCH net-next v9 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> --- net/rxrpc/rxkad.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 1bb9b2ccc267..29fe20ad04aa 100644 ---

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

ecent 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: Jason A. Don

[PATCH net-next v9 0/5] skb_to_sgvec hardening

nks to feedback from Dave Howells. Jason A. Donenfeld (5): skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ipsec: check return value of skb_to_sgvec always rxrpc: check return value of skb_to_sgvec always macsec: check return value of skb_to_sgvec always virtio_net: check ret

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

On Mon, May 15, 2017 at 3:11 PM, David Howells wrote: > skb_to_sgvec() can return -EMSGSIZE in some circumstances. You shouldn't > return -ENOMEM here in such a case. Noted. I'll fix this up for the next round.

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

On Mon, May 15, 2017 at 3:12 PM, David Howells wrote: > Is there a reason you moved skb_to_sgvec() in the file rather than just moving > the comment to it (since you moved the comment anyway)? 1) Because it's easier to understand skb_to_sgvec_nomark as a variant of

Re: Implementing Dynamic Rerouting in Kernel

On Thu, May 11, 2017 at 6:22 PM, Florian Fainelli wrote: > What you are looking for can be done using ipset-dns from Jason: > > https://git.zx2c4.com/ipset-dns/about/ Funny to see this project coming up. I actually ported this functionality into dnsmasq directly a few weeks

[PATCH v8 0/5] skb_to_sgvec hardening

ion. - Rebased against latest upstream ipsec changes. Jason A. Donenfeld (5): skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ipsec: check return value of skb_to_sgvec always rxrpc: check return value of skb_to_sgvec always macsec: check return value of skb_to_sgvec always virtio_

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

ecent 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: Jason A. Don

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

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "Michael S. Tsirkin" <m...@redhat.com> Cc: Jason Wang <jasow...@redhat.com> --- drivers/net/virtio_net.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/virtio_net.c b/dr

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

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Steffen Klassert <steffen.klass...@secunet.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: "David S. Miller" <da...@davemloft.net> --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 20

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

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> --- 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 1bb9b2ccc267..ecab9334e3c1 100644 ---

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

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Sabrina Dubroca <s...@queasysnail.net> --- 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 cdc347be68f2..dfcb1e9

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

On Tue, May 9, 2017 at 3:50 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1; (The next submission of this will take into account this + 1 here. https://git.zx2c4.com/linux-dev/log/?h=jd/safe-skb-vec )

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

(The next submission of this ipsec patch will have this rebased over the latest upstream tree. https://git.zx2c4.com/linux-dev/log/?h=jd/safe-skb-vec )

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

[PATCH v7 0/5] skb_to_sgvec hardening

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

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

ecent 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: Jason A. Don

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

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> --- 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 ---

  1   2   3   4   >