4 ms·
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
by zx2c4 10y ago
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.
- steveklabnik 10y agoI am extremely excited to see the Rust version of this; how do I learn about it when it ships?
- zx2c4 10y agoJoin the mailing list! https://lists.zx2c4.com/mailman/listinfo/wireguard https://lists.zx2c4.com/mailman/listinfo/wireguard And if you're savvy and want to get involved with development, we need all the help we can find!
- tinco 10y agoWhy 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?
- steveklabnik 10y agoI took it as "the Rust version is in userspace, and therefore will be slower than the in-kernel version."
- tinco 10y agoRight, 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 https://github.com/tsgates/rust.ko
- steveklabnik 10y agoElsewhere 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!)
- tinco 10y agoWhat 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 ;)
- steveklabnik 10y agoI would imagine very low.
- q3k 10y ago> Because it's necessary for any reasonable performance. This is simply not true [1] [2]. [1] - http://dpdk.org/ http://dpdk.org/ [2] - http://info.iet.unipi.it/~luigi/netmap/ http://info.iet.unipi.it/~luigi/netmap/
- loeg 10y agoBoth 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.)
- zx2c4 10y agoI 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.
- q3k 10y agoIt 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_interface.html http://dpdk.org/doc/guides-16.04/prog_guide/kernel_nic_inter...
- jpgvm 10y agoHowever 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.
- x0ra 10y agoOpenVPN is probably the worst VPN example. It carries about 15 years of technical debt... Same argument for OpenSSL. Unless you aim at gigabit speed, there is no real reason for a kernel based solution.
- hueving 10y ago>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. :(