netdev - Re: [PATCH net-next v2] net: WireGuard secure network tunnel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+arVNCYpJZsY7vMhBEKQsaig_o6j7E=ib4tF5d25c-cjw@mail.gmail.com>
Date:   Thu, 19 Dec 2019 12:18:43 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: WireGuard secure network tunnel

On Thu, Dec 19, 2019 at 11:53 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> On Thu, Dec 19, 2019 at 11:49 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> >
> > On Thu, Dec 19, 2019 at 11:11 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
> > >
> > > On Thu, Dec 19, 2019 at 11:07 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
> > > >
> > > > On Thu, Dec 19, 2019 at 10:35 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> > > > That's exciting about syzcaller having at it with WireGuard. Is there
> > > > some place where I can "see" it fuzzing WireGuard, or do I just wait
> > > > for the bug reports to come rolling in?
> > >
> > > Ahh, found it: https://storage.googleapis.com/syzkaller/cover/ci-upstream-net-kasan-gce.html
> > > Looks like we're at 1% and counting. :)
> >
> > Yes, that's it. But that's mostly stray coverage.
> > wg_netdevice_notification I guess mostly because it tested _other_ device types.
> > And a bit of netlink because it sends random garbage into netlink.
> >
> > For netlink part it would require something along these lines:
> > https://github.com/google/syzkaller/blob/master/sys/linux/socket_netlink_generic_devlink.txt
> > https://github.com/google/syzkaller/blob/master/sys/linux/socket_netlink_crypto.txt
> > https://github.com/google/syzkaller/blob/master/sys/linux/socket_netlink_generic_fou.txt
> > https://github.com/google/syzkaller/blob/master/sys/linux/socket_netlink_generic_seg6.txt
> >
> > And for device setup, harder to say. Either pre-create one here:
> > https://github.com/google/syzkaller/blob/79b211f74b08737aeb4934c6ff69a263b3c38013/executor/common_linux.h#L668
> > or teach it how to create them on the fly or both or something else.
> >
> > Probably some wire packet formats here:
> > https://github.com/google/syzkaller/blob/79b211f74b08737aeb4934c6ff69a263b3c38013/sys/linux/vnet.txt
>
> Ahh, cool, okay. Netlink, device creation, and basic packet structure
> is a good start. What about the crypto, though?

It depends. What exactly we need there?
syzkaller uses comparison operand interception which allows it e.g. to
guess signatures/checksums in some cases.
We also have this special checksum type in descriptions:
https://github.com/google/syzkaller/blob/79b211f74b08737aeb4934c6ff69a263b3c38013/sys/linux/vnet.txt#L462
which means "fill in other data, then calculate the checksum and put
in that location".
Other things can be done in a similar way, e.g. some crypto. But that
requires more effort and leads to a tradeoff between effort/gain.
Generally we like smaller set of more generic constructs in
descriptions that can help with a set of different kernel interfaces.
But if it's lots of custom support for a single very special case,
then it becomes somewhat questionable.
But we have some ugly hack for such cases as well, e.g. for netfilter
we just say "screw it, so many special one-off cases, so we will just
write one-off procedural code":
https://github.com/google/syzkaller/blob/79b211f74b08737aeb4934c6ff69a263b3c38013/sys/linux/init_iptables.go
But generally we try to avoid that (and/or later replace ugly custom
code with generic constructs).