It's not possible to do highspeed crypto from userspace while still integrating with the usual networking stack. Tun devices result in copies and context switches which makes things quite slow.
This also adds quite a bit of simplicity.
But sure, I agree, it's scary. But not nearly as scary as the obscenely huge xfrm/ipsec layer in the kernel. Or the dozens of other kernel tunneling deivces available. And I dare even say it's not as scary as most userspace VPN solutions like OpenVPN which are massive code bases. WireGuard, in contrast, aims to be quite minimal in its codebase, so that it can be audited by an individual.
I didn't make the title of this HN post, unfortunately. But do note: there _will_ be userspace implementations of WireGuard. It's most certainly not tied to the kernel. It's just that the OP saw me present at a kernel conf about it. :P
Not trying to discount the author's work, and I haven't reviewed any of the documentation, but until this gets evaluated by a CC lab (or like independent group) I would not implement in anything you care about.
First, this is Linux, and if someone manages to get code execution in your unprivileged userland program, the odds of you keeping them out of your kernel are already pretty low.
Second, and more importantly, this is VPN software. If your VPN gets popped, you probably have bigger problems than whether the attacker got the kernel on the VPN server, as opposed to just being able to create arbitrary network connections from the "inside" of the VPN.
If you don't want to run it, don't run it. If you're going to ask me whether I'd trust OpenVPN more than WireGuard, no, I do not.
As a "kernel professional", I'm laughing incredulously at this. A lot.
The end goal ought to be getting more things out-of-ring 0, not adding more things to it -- I'm never going to say that "I'm not concerned" or that "It's a non-issue" (although I will say that I'm a lot more worried about the massive amounts of crap code in WiFi drivers than I am about a VPN implementation, generally speaking).
In the OpenVPN case, numerous vulnerabilities have been limited to only DoS exploits due to the zealous use of assert(); in the kernel case, that brings down your machine, and quite often, assertions are compiled out of the release kernel due to their overhead in critical paths (whether they should be is another question).
We do have ways to tackle the kernel->userspace performance divide when it comes to packet processing, e.g: https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4
netmap is a framework for extremely fast and efficient packet I/O for
both userspace and kernel clients. It runs on FreeBSD and Linux, and
includes VALE, a very fast and modular in-kernel software switch/data-
plane, and netmap pipes, a shared memory packet transport channel. All
these are accessed interchangeably with the same API.
netmap, VALE and netmap pipes are at least one order of magnitude faster
than standard OS mechanisms (sockets, bpf, tun/tap interfaces, native
switches, pipes), reaching 14.88 million packets per second (Mpps) with
much less than one core on a 10 Gbit NIC, about 20 Mpps per core for VALE
ports, and over 100 Mpps for netmap pipes.
Userspace clients can dynamically switch NICs into netmap mode and send
and receive raw packets through memory mapped buffers. Similarly, VALE
switch instances and ports, and netmap pipes can be created dynamically,
providing high speed packet I/O between processes, virtual machines, NICs
and the host stack.OpenVPN uses TLS. The whole point of WireGuard is to shake off that complex baggage.
I sometimes think Apple removed /dev/tap from iOS because it provided too much potential freedom.
Not every user needs in-kernel performance for their daily routine but there's certainly an argument that every user could use a decent "VPN" that could run on all their computers.
Alas, OpenVPN mindshare is rather strong, to the detriment of existing or future userspace alternatives.
Granted, but this should generally be behind a shared secret HMAC, according to best practices, limiting the scope to those with the key in hand.
> The whole point of WireGuard is to shake off that complex baggage.
That's great, but also has nothing to do with running in-kernel. I'm not ready to give either product a clear pass on their risk profiles.
It kind of seems to fly in the face of the multiple layers of userland and kernel separation engineering we've seen go into other attack surfaces like browsers?
But all things are not equal. Any code execution on the VPN server practically implies that the attacker controls the VPN, which is game-over for most VPNs I've ever worked with. So my priority would be "not having those kinds of vulnerabilities at all". I'd rather have simpler, easier-to-audit code than userland, if I have to choose one.
"If someone manages to get code execution in your
unprivileged userland program, the odds of you keeping
them out of your kernel are already pretty low."
https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.p...
Are you running the grsecurity patches? If not, everything they do that your kernel doesn't do is another reason your userland will inevitably cough your kernel up to an attacker at some point. Even with those patches, it's still an inevitability; it's just that interval is longer.
I don't run them! I do something easier: I assume that if I lose control of userland on a Linux machine, I've lost the whole box.
It is especially weird, though, to see security people engaging in this kind of risk reasoning. It seems to me that most of the times you lose code execution on your VPN server, the kernel security of the VPN server is pretty far down the list of problems you need to deal with.
So, despite severity of VPN-level compromise, there's advantages mainly in detection and damage limitations if it's a strongly-constrained process. Hell, I've done prototypes that used fixed memory with only networking privileges needed that logged their own behavior to immutable storage. You could compare the execution and logging to a profile. Outside that range, it was a crash or attack. Clive Robinson taught me that last part. Others were Orange and Red Book 101.
You may be surprised, then, that most of the standard VPN tech — IPsec, GRE+PPTP, VxLAN, etc. — operate in the kernel (with some help from userland apps for things like IKE).
http://genode-labs.com/publications/mikro-sina-2005.pdf
Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.