
WireGuard Merged into OpenBSD - axiomdata316
https://marc.info/?l=openbsd-cvs&m=159274150512676&w=2
======
zx2c4
WireGuard project announcement is here:
[https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588...](https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588.html)

~~~
riobard
What's the performance situation of the wg-go implementation now? I recalled
there's a utun device API limitation that each packet requires a syscall. Is
there any progress to avoid the overhead?

~~~
vertex-four
I imagine that io_uring or similar work could help here - provide the kernel
with a submission queue and a completion queue once, and just keep feeding it
buffers to fill without syscalls.

~~~
riobard
That's what I'd assume but I've never seen anyone doing that yet.

~~~
vertex-four
That would be because io_uring is incredibly new and I don't think the tuntap
driver supports it yet.

------
athoik
Just great!

Hope to release wireguard on FreeBSD soon as well.

In order pfSense to include it:
[https://redmine.pfsense.org/issues/8786](https://redmine.pfsense.org/issues/8786)

~~~
throw0101a
> _Hope to release wireguard on FreeBSD soon as well._

Available as a Port / package:

* [https://www.freshports.org/net/wireguard/](https://www.freshports.org/net/wireguard/)

* [https://www.freshports.org/net/wireguard-go/](https://www.freshports.org/net/wireguard-go/)

Running it in a jail for further compartmentalization:

* [https://genneko.github.io/playing-with-bsd/networking/freebs...](https://genneko.github.io/playing-with-bsd/networking/freebsd-wireguard-jail/)

* [https://news.ycombinator.com/item?id=23004061](https://news.ycombinator.com/item?id=23004061)

~~~
loeg
GP is referring to the kernel implementation that is a work-in-progress.

~~~
clort
A kernel implementation also in development on NetBSD:

[https://github.com/ozaki-r/netbsd-
src/tree/wireguard](https://github.com/ozaki-r/netbsd-src/tree/wireguard)

------
atonse
I’ve always wanted to run OpenBSD for our Wireguard bastion host (the one
machine that is “open”. Not sure it makes a difference over Linux but OpenBSD
has an even stronger security culture.

Was satisfied with the state of affairs before but genuinely excited about
this development.

~~~
tptacek
OpenBSD has a different security culture. "Stronger" hasn't been the right
word in over a decade.

~~~
jooize
What do you mean?

~~~
woodruffw
OpenBSD has historically been eager to add new security mitigations without
explaining their intended threat model.

Here's an excellent talk (in website form) on the subject:
[https://isopenbsdsecu.re/about/](https://isopenbsdsecu.re/about/)

~~~
bawolff
I dont think that website is very compelling. It claims a bunch of things as
not good practise, and then asserts without evidence or example that openbsd
does them.

Quite frankly it reads like someone with an axe to grind against openbsd.

~~~
woodruffw
> I dont think that website is very compelling. It claims a bunch of things as
> not good practise, and then asserts without evidence or example that openbsd
> does them.

Here's a material example: OpenBSD has expended considerable effort into
removing ROP gadgets from their compilation products[1].

As the website documents[2], these efforts haven't made a single exploit
harder to write.

GCC even removed their (mostly equivalent) ROP mitigation approach,
documenting it as "fairly ineffective" and "lur[ing] developers to the land of
false security"[3].

(Another good example is PID randomization: OpenBSD added this over 20 years
ago as part of their "randomize anything that can be randomized" approach.
It's never had any real positive security impact, and has made _other_ PID-
based vulnerabilities more viable.)

[1]:
[https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf](https://www.openbsd.org/papers/eurobsdcon2018-rop.pdf)

[2]:
[https://isopenbsdsecu.re/mitigations/rop_removal/](https://isopenbsdsecu.re/mitigations/rop_removal/)

[3]: [https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-
wa3...](https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-
wa3wBaH4cNmvW=nxMYDgXtybinE4sg5EmsAgtasMA@mail.gmail.com/)

~~~
sanxiyn
I agree some OpenBSD security mitigations are dubious, but if I am forced to
choose between Linux (too little) and OpenBSD (too much), it seems to me
OpenBSD is definitely preferrable. (Of course, the best is to implement only
effective ones.) Do you disagree?

~~~
woodruffw
I think that Linux is a security mess in its own ways.

That being said, I think Linux’s guts get _far_ more attention than OpenBSD’s
do, and that the (fewer) mitigations that Linux chooses to implement are much
better supported by both information on real-world attacks and by the
literature. Given that, I have a slight preference for Linux. But that
shouldn’t be taken as praise.

------
cpach
Very good call from the OpenBSD project to include this in their kernel.

------
bch
WireGuard:
[https://en.wikipedia.org/wiki/WireGuard](https://en.wikipedia.org/wiki/WireGuard)

------
greatjack613
Incredible, so excited to see wireguard start making it into mainstream
distros.

Personally I see this as the most exciting thing to happen to linux in the
past 2 - 3 years.

~~~
asveikau
Enthusiasm noted, but OpenBSD is not Linux.

~~~
talideon
My guess is that GP is referring to WireGuard, not this specifically.

------
Tsiklon
Congratulations to the team on this successful integration into OpenBSD.

I'm really pleased to see ongoing Wireguard integration in all the big
platforms.

The setup is so simple, I route all my personal traffic through a simple cloud
based WG + Pihole setup.

------
jjice
Why does WireGuard need to be a part of the kernels for BSD, Linux, and I
assume other OSes? Is OpenVPN the same way? Why can't it be part of userspace?

~~~
detaro
It doesn't need to be, a userspace implementation is available.

------
schoolornot
Does the underlying crypto in WireGuard lend itself to hardware
acceleration/implementation in ASICs? If so, when do we expect to see such
devices available?

~~~
867-5309
I believe Wireguard is up to 4x faster than OpenVPN where OpenVPN uses AES-NI.
processors with this instruction set is possibly the closest thing to an ASIC
for VPN en/decryption, so I dare say Wireguard will neither need nor benefit
from a purpose-built instruction set

~~~
api
AES is as fast or faster than ChaCha if there is hardware acceleration.
OpenVPN is slow for other reasons, and honestly the crypto is usually not the
bottleneck in most cases unless you are really pushing multiple gigabits or
it's a very small CPU.

~~~
throwaway2048
This is definitely not true, chacha20 is frequently faster than AES even with
AES-NI in use, especially on earlier implementations of the instruction
extension.

~~~
api
I'd like to see some numbers on this. I'm sure there are some chips where it's
the case but are we talking small ARM cores or larger desktop and server
chips?

------
grogenaut
still waiting for wireguard to be TCP based so I can use it in large
corporations, many of who don't dig stateless udp in their firewalls.

~~~
bawolff
Wat?

If wireguard doesn't meet your requirements, don't use it, but its kind of
rediculous to complain it doesn't do X when doing X would defeat the point of
the software.

------
nindalf
I’m confused about their mention of Go. The Linux implementation of WireGuard
is written in C - [https://git.zx2c4.com/wireguard-
linux](https://git.zx2c4.com/wireguard-linux)

~~~
skrause
OpenBSD doesn't want any GPL code, so they couldn't just port the Linux kernel
module.

The OpenBSD kernel module is also written in C:
[http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/sys/net/if_wg.c...](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/sys/net/if_wg.c?rev=1.3&content-type=text/x-cvsweb-markup)

But the code looks quite different from [https://git.zx2c4.com/wireguard-
linux/tree/drivers/net/wireg...](https://git.zx2c4.com/wireguard-
linux/tree/drivers/net/wireguard?h=stable)

~~~
zx2c4
This has nothing to do with licensing. OpenBSD is a different kernel, so
different code. Having written the Linux code, I relicensed any similarities
between the two to make it amenable to OpenBSD, and remove any doubt about
status.

~~~
aljarry
Is it possible to create kernel modules for both OpenBSD and Linux with common
code that's licensed appropriately? Something like a library with two kernel
API glue layers, one for Linux GPLed and one for OpenBSD.

~~~
aargh_aargh
My impression about the goal of Wireguard (mind you, I haven't looked at the
code) is that it's to be as simple as possible, reusing as much of the
primitives the OS offers without reinventing the wheel.

That goal may be antithetical to a single codebase supporting multiple
(possibly very dissimilar) operating systems.

It's interesting to compare this approach to the approach taken by OpenSSH
(and its openssh-portable variant). One has code specific to each OS, the
other one has one canonical codebase for one OS + patches addressing
compatibility with other OSes. IMHO mostly due to the difference in complexity
of each project.

