Hacker News Reader

Comment by wolverine876 | Hacker News Reader

There's a good description here of what they're doing: https://lists.zx2c4.com/pipermail/wireguard/2021-August/0068...

I am curious (though happy) about their focus on performance. For most security projects, the specification seems to be 'sufficient' performance and beyond that they invest their limited resources elsewhere. The WireGuard team seems to make it a top priority.

Maybe this upgrade was needed to be 'sufficient'? Maybe they see performance as key to adoption? Or maybe they have other reasons. I could see how WireGuard's significant reduction in complexity, compared to other VPN software, could feed performance.

It's hard to imagine the Internet without WireGuard, without a VPN I have confidence in. Thank you Jason and team!

View on HN

Security is the top priority. But being useful is also important; if nobody can use it, nobody benefits from that security. Acceptable performance is very important for being useful, especially when tunneling layer 3 packets, where latency has rippling effects. The prior non-kernel WireGuard for Windows simply was not sufficiently useful for real world workloads people wanted to run, because of the lower performance, both on servers and on laptop wifi alike.

A big part of the WireGuard project since the beginning has been trying to figure out how to do high security tunneling that also performs acceptably. It's easy to do one without the other, but doing them both together has meant thinking about a lot of fundamentals, from the protocol state machines on up. It's hard to do tunneling in the kernel at high speed while still maintaining a strong security posture. That's a principal challenge the project endeavors to solve.

More generally, it's worth noting that cryptographers also care about performance quite a bit in things like symmetric crypto. We know well how to make a good cipher now, but making one that also performs at increasingly high speeds remains an open area of research, with whole conferences, such as FSE, devoted to it.

Seems to me like if you need to do your task inside the kernel to get acceptable performance, there's something wrong with that kernel.

It's also arguably more difficult to do a given task in the kernel than in userland, code for the kernel is much more security-sensitive and even subtle bugs can be detrimental to overall system performance (or even exploitable).

Best thing would be to fix the OS instead of piling up kludges.

What do you suggest that the Wireguard team should do about that?

Basically all high performance VPN implementations are kernel-mode. Just because something is difficult does not make it automatically wrong. Note that the main userland VPN which gets cited (OpenVPN) has terrible battery and latency performance.

https://arstechnica.com/gadgets/2020/03/wireguard-vpn-makes-...

https://www.freebsd.org/cgi/man.cgi?query=ipsec&sektion=4&fo...

How would one circumvent the need to copy traffic between different userspace processes before it leaves the host in the case of a userspace tunnel implementation? With a kernel implementation, the userspace process sends some data to a socket, and then the kernel can directly pass the data to the tunnel implementation with as little copying as the design for the kernel allows, and as little context switching as the design allows.

> How would do one circumvent the need to copy traffic between different userspace processes

By mapping the same buffer into both processes, or moving it from one process to the other, depending on security needs. Mapping the buffer into multiple memory spaces is how a kernel VPN driver would accomplish the same thing.

> as little context switching as the design allows

A raw context switch only costs 20 nanoseconds for a round trip. And it's only a few more to save the normal registers. The rest is up to kernel design. So it sure sounds like it's the kernel's fault if putting tasks like that outside the kernel is too expensive. Especially since one context switch can process as many packets as you want.

These days a lot of the context switch delays come from security mitigation’s due to vulnerable processors.

Flushing TLBs. Flushing caches. Etc etc.

Wintun -- https://www.wintun.net -- actually uses this technique via shared memory ring buffers. And Winsock RIO has something similar for packets. We were using both of these already prior to WireGuardNT. They're fast but not conclusively so.

"How would one circumvent the need to copy traffic"

Fixing that is the point of, for example, io_uring in Linux. I don't know if Windows has an equivalent. Perhaps not, thus a kernel driver. But there is nothing mysterious about solving that problem.

The original, canonical implementation of WireGuard on Linux predates io_during, and Windows has had IOCP for decades now.

Hear, hear! I've always said microkernels are the best. If you have thousands of drivers in your kernel, each one is just another attack surface, something that can take the machine down on something as simple as RS232 traffic. Instead drivers should be isolated in their own process. It has lots of advantages:

* Dynamic loading of drivers is no longer an issue, the kernel already knows how to dynamically load processes anyway and a driver is just another proces. No need for special 'kernel maintainers' for drivers, or for drivers to be open source (in case of the Linux kernel).

* Much better system stability, since drivers can do no harm. Kernel architecture can be simpler too.

* Much simpler drivers. Instead of strict cooperation rules the kernel can just pre-empt them when needed.

Unfortunately it appears there is no credible effort in developing a mainstream microkernel OS at this time. Nonetheless, the few I've worked with in the past were amazing and I'd love to see this idea come back.

Context switching overhead is bad for microkernel performance. All the reasons why the userspace wireguard implementation was slower apply to each and every part of a microkernel system. And all of this got worse with spectre and meltdown, secure context switches are now even more expensive. Modern CPUs generally always increase the context switching cost, they optimize for single-process benchmarks.

So microkernels are dead, performance buries them deeper and deeper.

The world is mired in IPSEC and OpenVPN, two of the Internet's great buzzing stagnant water pools. Part of the reason for that is that proponents (anyone who has gotten IPSEC working is inclined to be a proponent, since it's an investment of effort and brain space one might reasonably hope would pay off) can appeal to standards, known-quantity-ism, and multi-vendor ecosystems.

Legacy VPN protocols fare terribly against WireGuard on what should be the most important concern, of design and implementation security. But the reasons why are, though obvious to people with domain expertise, subtle enough that you can't mic-drop them in a conversation and expect to overcome the standard "but it's standard" objection in favor of IPSEC.

Performance has been a potent tool of persuasion for WireGuard. I've convinced people based on WireGuard speed that I don't think I could have persuaded based on security.

If the goal is getting people off fetid 1990s-grade cryptography and C code, WireGuard's performance is an indirect force towards that goal. It was smart to focus on it, because people obviously care a lot about it. It's great to see a security project where simplicity and performance line up with improved security.

> anyone who has gotten IPSEC working is inclined to be a proponent, since it's an investment of effort and brain space one might reasonably hope would pay off

Oh dear me, getting IPSEC to work did not win it any admiration from me. Of course, what I was doing with it would have been better served by TLS with server and client certificates, but the other end were telcos so sure, I can setup IPSEC and cry myself to sleep.

If I could I would instantly replace every L2L IPsec tunnel configured everywhere I have access, but unfortunately until Cisco, Juniper, Fortigate etc. implement Wireguard, IPsec remains the only option.

I am already using it for production purposes where both endpoints are Linux, though.

> subtle enough that you can't mic-drop them in a conversation and expect to overcome the standard "but it's standard" objection in favor of IPSEC.

I wonder if we shouldn't standardize something very similar to wireguard as a general successor of ipsec.

Something like wireguard + iana/ietf considerations.

Exposing WireGuard to the standards process is the absolute last thing we should do with it. I mean that literally.

Yeah I don't think it would be wise to hurry it up.

I was just thinking that it'd be nice to have something a-la wireguard standardized.

Hi Jason, are there any plans for process based routing within the WindowsNT driver? For example, if a Windows user wanted to route only Chrome through a Wireguard tunnel but leave all other applications network traffic untouched.

Routing is actually a layer before packets make it to the WireGuardNT miniport driver. Usually the routing table controls this, but WFP callout drivers can also steer traffic to specific adapters based on things like process image path or security descriptor. So for this functionality, WireGuardNT can be used with various WFP drivers or routing table configurations. It's not something that'd belong in WireGuardNT itself.

With regards to the WireGuard for Windows client, though, whether we'll put the time in to develop such a WFP driver and integrate it there I guess is still up in the air, like many feature wishlist items are.

Okay that makes sense, thanks for the info. I'm new to Windows networking and thought WireguardNT was somehow using a WFP callout to encrypt plus reroute packets and then drop the original. Keep up the great work you're doing!

> It's hard to imagine the Internet without WireGuard, without a VPN I have confidence in. Thank you Jason and team!

Most of the time I forget i'm even using wiregaurd until I hit a site that blocks non-consumer IPs, which I think says a lot for just how performant it is - More than simply not slowing down the connection much, it's actually improved reliability considerably for me since I started using it a couple of years ago, in some cases throughput is also improved due to better routing.

It's also made a huge difference to the stability of my SSH connections, making my day to day work a lot more pleasant. Before, SSH connections would arbitrarily drop due to carrier grade NATing ignoring TCP keep alive rules... it's almost impossible to find a consumer ISP these days that doesn't drop idle SSH connections like rocks. With wiregaurd I can keep them alive even while I change connections! my tmux use has dropped to when I actually need to multiplex.

> The WireGuard team seems to make [performance] a top priority.

Well, if people adopt WireGuard because it's really fast, they'll also end up with a relatively secure VPN. Together, it's really compelling.

I think performance is just a top priority as security, I remember how in their first whitepaper they already talked about how they batch up packets and stuff like that. Also the whole approach of kernelspace instead of userspace is just for performance.

Actually, I think in the beginning there was even a "marketing chart" with throughput numbers in addition to the chart with lines-of-code numbers?

Edit: performance being a top priority also makes sense strategically: if you want people to use secure software en-masse, then the experience needs to be stellar in UX and performance as well.

> I think performance is just a top priority as security ...

That's my impression too. Nothing wrong with it, but I wonder what their thinking is.

> For most security projects, the specification seems to be 'sufficient' performance and beyond that they invest their limited resources elsewhere.

I think this impression is basically mistaken, but I'd love to hear about any examples you have in mind.

It may be mistaken but to be clear, I don't mean it critically. Most FOSS projects have very limited resources - most FAANG projects have limited resources (and skip the security to invest in addictive user experiences and data collection). If security is the aim, it's wise to spend the resources there.

An example? Signal. I love it but performance isn't more than sufficient IME. I'm glad Moxie and crew are spending their time inventing new security technology for the world.

Reply on news.ycombinator.com