On Thu, Dec 19, 2019 at 11:53 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > On Thu, Dec 19, 2019 at 11:49 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > > > On Thu, Dec 19, 2019 at 11:11 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > > > > > On Thu, Dec 19, 2019 at 11:07 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > > > > > > > On Thu, Dec 19, 2019 at 10:35 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> 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).
