Hacker News new | past | comments | ask | show | jobs | submit login

Because it's necessary for any reasonable performance. If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel. IPsec is the only other alternative for high speed VPNs, and it's frighteningly complex, both in deployment and in codebase.

WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows for a single individual to audit it. By focusing on simplicity and ease-of-auditability, I hope to achieve something that can be considered secure.

Compare this to the massive codebase of OpenVPN/OpenSSL and the various other userspace (read: slow as mollasses) VPNs. WireGuard is considerably shorter and simpler than those too.

Also, keep in mind that on Linux, jumping from userspace to ring0 execution isn't exactly difficult. So in practice I'm not sure it matters.

I make a living by exploiting kernels. This makes me very aware of the questions associated with running this in the kernel. I've tried to write WireGuard using my experience breaking similar codebases; WireGuard is short enough that it should receive the thorough attention that this sort of software deserves. By focusing on simplicity, I think we can in time achieve something quite trustworthy.

Finally, there will be a (necessarily lower speed) cross platform implementation released that's written in Rust. At the end of the day I suspect that all parties will find themselves pleased.

> Because it's necessary for any reasonable performance.

This is simply not true [1] [2].

[1] - http://dpdk.org/

[2] - http://info.iet.unipi.it/~luigi/netmap/

I love DPDK. Super fun. I've actually made a few projects with it. But this is for creating closed network systems, not for integrating into Linux's networking infrastructure. If somebody would like to produce a WireGuard implementation (library, I guess) for DPDK, I'd be super happy about this, and I'm sure it'd find some specialized users. But for everything else, there's the ordinary design.

It is absolutely possible to create DPDK applications that send/receive data into the Linux network stack using KNI [1]. I'm not sure if I'm qualified to say whether DPDK is “for” something, but the means to achieve this exist.

[1] - http://dpdk.org/doc/guides-16.04/prog_guide/kernel_nic_inter...

Both userspace stacks bypass several standard kernel interfaces to achieve good performance. If you want to integrate with normal kernel configuration (interface, routing, etc) and BSD sockets, then maybe you do need to be in the kernel. (Maybe it's possible to improve user<->kernel interfaces to reach good performance in userspace with standard kernel configuration, but we aren't there yet.)

However it's basically true. You need to be running specific hardware and/or drivers to make use of kernel bypass. You most definitely will never be able to use DPDK on the average laptop.

For a VPN that intends end-user device deployment it's kind of silly to require specific hardware.

I am extremely excited to see the Rust version of this; how do I learn about it when it ships?

Join the mailing list!


And if you're savvy and want to get involved with development, we need all the help we can find!

Why necessarily lower speed? Are you hinting at bounds checking? I would think that a rust implementation might have slightly more pressure on the CPU but would not effectively be slower. Am I wrong?

I took it as "the Rust version is in userspace, and therefore will be slower than the in-kernel version."

Right, I heard about the Rust kernel module[1], but perhaps its environment isn't friendly enough yet to attempt to port a project like this to?

edit: Just read a little bit of its source, apparently you have to disable std, and he replaces it with his own linux_std that at this point has only printf implemented. So yeah it'd be a pretty intense project if one would attempt it :)

1] https://github.com/tsgates/rust.ko

Elsewhere in the thread, they talk about upstreaming some code into the kernel itself; so it has to be in C for that. That's my guess, anyway.

(disabling std is standard in environments like this; and you still get libcore, which is a lot of stuff!)

What are the odds of getting Linus to approve of Rust? It would be the greatest thing ever. Imagine the impact on the C++ community.. You might say I'm a dreamer, but I'm not the only one ;)

I would imagine very low.

>If you're concerned about this, you might have several heart attacks when you look at the obscene amount of code that IPsec has in the kernel.

I know and I don't much care to see this crappy tradition carried on with this new protocol. :(

Applications are open for YC Winter 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact