WireGuard Merged into OpenBSD | Hacker News Reader

WireGuard Merged into OpenBSD

marc.info

410 pointsaxiomdata31697 comments

WireGuard project announcement is here: https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588...

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?

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.

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

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

Just great!

Hope to release wireguard on FreeBSD soon as well.

In order pfSense to include it: https://redmine.pfsense.org/issues/8786

hopefully OPNSense gets the same soon. they already ship it (i think as a kernel module).

> 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-go/

Running it in a jail for further compartmentalization:

* https://genneko.github.io/playing-with-bsd/networking/freebs...

* https://news.ycombinator.com/item?id=23004061

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

A kernel implementation also in development on NetBSD:

https://github.com/ozaki-r/netbsd-src/tree/wireguard

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.

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

Yeah I don’t know if at this point it even matters. I was nervous about even leaving this comment. Maybe showing my decade old bias.

I use alpine for my bastion machine, but I'm not even sure if it's the best solution.

Same sentiment here. I could come up with one "advantage" of OpenBSD over Linux - smaller user base. In a simplistic kind of a view that should make it less compelling to put in as much effort into developing exploits vs more common OS'. I couldn't back this up with any concrete data though.

Security through obscurity isn’t foolproof, but it isn’t entirely foolish, either. It can reduce risk if part of a layered defense strategy.

It is important to remember though that it is not the number of users but but the value of the compromise that determines how compelling the O/S is. There are like vintage mainframe O/Ses for which folks are actively developing compromises because some government or telco hasn’t migrated off. Then again, those teams aren’t going to waste a exploit on somebody’s home Usenet archive.

TL;DR: nevermind. I am too busy arguing with myself to be coherent.

What do you mean?

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/

In the face of the Linux kernel not taking care of known exploits, regardless of their usability, I'll take it.

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.

> 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

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

[3]: https://patchwork.ozlabs.org/project/gcc/patch/CAFULd4ZL-wa3...

Where are all the OpenBSD exploits that bypass these mitigations? Serious question.

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?

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.

at the time, lots and lots of scripts would place things in /tmp/scriptname-$PID so you could race them, since you can know where it will write things, other scripts would use PID for random which is equally bad, especially for things that run from rc scripts at startup, so I would say "nothing was gained" is a bit of a stretch.

After a while, mktemp got more usage (which is good) and $RANDOM became available for scripts and so forth, but the situation was quite bad 20+ years ago as far as vendor installation scripts went.

Perhaps exactly noone was saved on OpenBSD because few installed linux-compat Netscape 1.1N for i386 with a bad installation script while having adversarial users logged in, but there is no reason to be equally bad as the then-more-popular OSes who did see /tmp races being won by users.

I think the review on that website is actually more mixed than "axe to grind". I just spent some time reading the "mitigations" section. Some mitigations are criticized as questionable or easily defeated, but others are praised for a good implementation.

At any rate, I think some people may forget what stock Linux distros or even a commercial *nix install used to look like at the default install, before people like the OpenBSD folks raised awareness of some of these issues. In the late 90s I recall default installs elsewhere that had a bunch of ports open and no firewall right out of the box in a default install. In the same timeframe OpenBSD was making a bit of a PR-ish stink about a secure default install. In the same timeframe OpenSSH came on the scene.

But honestly, there are a few things that OpenBSD is only really just starting to get really right in the last few years. syspatch and pkg_add-able binary updates in the stable branch are two that come to mind. Also sysupgrade; I used to dread upgrading OpenBSD [xkcd had the joke about it leading to shark attacks], but now it's really simple.

If you look at some of the comments, sources, and just the attitude of the guy that put this together it seems he does have an axe to grind. It kinda says so in the about section. I think if you dive into the mitigations section without looking at that it seems less like that because he ends up having to admit some of them are decent ideas... try as he might to come up with ways in which they're not. There are plenty of OpenBSD users going around talking nonsense but this "systematic evaluation" is not an actual systematic evaluation.

I especially like the part where it lists people who helped but it's all redacted. All of this "research" came from google and twitter. I'd like to see some bypasses to OpenBSD's mitigations and perhaps some ideas and/or code to help improve them or implement ones that these folks say work better. If they're all so bad then it shouldn't be hard for someone like the author or so called security experts he quoted to do these things. Yeah, maybe no one is going to pay for that work to be done... that seems to always be the response when someone asks for proof, code, etc. No one has the time. They sure spend enough time making websites, blog posts, and tweeting about it though.

The guy who wrote this did a talk about it, this website was to list sources etc. I’m an OpenBSD user and I did not personally feel like he had an axe to grind, and overall thought he was fair and had well made points. I’ll be the first to admit a lot of what he said was rather too technical for me, but if I’m remembering correctly I never saw many counter points to his claims.

I personally feel that OpenBSD is more secure for my use case, but I’m happy that people bring up points like this as humans make mistakes and not even OpenBSD is perfect.

I watched the talk. The guy was wearing a t-shirt with the OpenBSD mascot with "got hacked" under it. Again if you read the about section it seems pretty clear. You're parroting the same language from the talk. Why should there be counter points to some random internet person's claims? Where are those bypasses at? Where are the patches to incorporate these better mitigations or to improve existing ones?

I don't think OpenBSD has perfect security and I'm not sure why that needs to be said. I don't see anyone involved in the project making that claim either. What I'm saying is this talk/website is just as dubious as some of y'all think OpenBSD mitigations are and if that's not obvious from looking at the sources I'm not sure what else to say here.

Is anyone denying that OpenBSD's mitigations follow those practices? You can look at OpenBSD's own presentations about, say, pledge, and it seems like that website's characterisation is fair: no characterisation of what the threat model is, what vulnerabilities this is intended to make impossible, and no assessment of whether it actually succeeds in this.

Im not super familar with openbsd or pledge, but isn't pledge just an extension of standard privledge segregation stuff? People have been using privledge segregation for decades at this point.

Privilege separation has indeed been in use for decades, but the same criticisms apply to it (and indeed it seems to mostly be an OpenBSD technique).

And I think it is rather obvious. Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console.

Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777?

One can then put up an angry webpage claiming people who chmod their keys are crap at security, it is uneffective, no listing of what it even was meant to protect against and of course no hard numbers to it. But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.

> Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console.

Does that improve security? By how much? What exploitation would it have prevented? At what cost? If you're not measuring the impact then it's pretty much voodoo security.

> Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that.

Then that guide is of little practical use. On a multi-user server that chmod makes sense. Inside a single-user container/VM, it's completely pointless. If the guide isn't telling you what the threat model is, you have no idea whether the mitigations you're applying are relevant or not.

> No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777?

Yes! Of course. Would you not?

> But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.

If you think that's a real danger then include it in your threat model. Maybe SELinux is harder to understand, or configure, or too many people have access to its settings. Maybe it's the opposite (I've seen junior admins chmodding everything to 777 many times, I've yet to see one turn SELinux off). Either way, you need to explain that so that people understand it, otherwise you're encouraging people to cargo cult their security practices.

See https://www.openbsd.org/security.html and https://www.openbsd.org/innovations.html

Some snippets:

> OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make. Also, since OpenBSD is exported with cryptography, we are able to take cryptographic approaches towards fixing security problems.

> ASLR: OpenBSD 3.4 [Nov 2003] was the first widely used operating system to provide it by default.

> W^X: First used for sparc, sparc64, alpha, and hppa in OpenBSD 3.3. Strictly enforced by default since OpenBSD 6.0: a program can only violate it if the executable is marked with PT_OPENBSD_WXNEEDED and it is located on a filesystem mounted with the wxallowed mount(8) option.

> Kernel relinking at boot: the .o files of the kernel are relinked in random order from a link-kit, before every reboot. This provides substantial interior randomization in the kernel's text and data segments for layout and relative branches/calls. Basically a unique address space for each kernel boot, similar to the userland fork+exec model described above but for the kernel. Theo de Raadt, June 2017.

I use it for critical functions largely because it is simpler.

> OpenBSD has an even stronger security culture.

BIG citation needed.

> Not sure it makes a difference over Linux

It doesn't.

Edit: listen, I understand that people are religious about their operating system kernel, but please make a reply to these points if you have one to refute.

Because OpenBSD is security snake oil. Linux and FreeBSD are more secure than OpenBSD.

That is a surprising claim. You should substantiate it with evidences, say, on exploits.

FreeBSD was a joke on defaults. Look:

https://vez.mrsk.me/freebsd-defaults.html

On Linux, I won't even start on the policy on most distros.

> > OpenBSD has an even stronger security culture.

> BIG citation needed.

While it may be debatable how much of an effect the OpenBSD security culture has on real world security outcomes, it is pretty obvious to most people I think that OpenBSD has a culture of security (or a focus on it) that Linux simply does not have. Security is practically the entire branding of the project. Just go to its home page, literally the first sentence is an advertisement for its security record. The culture is very much there, regardless of results.

Now, if you did want to argue that the security culture does not necessarily result in better outcomes, 1) that intention should probably be made more clear, and 2) why not at least provide an argument or some amount of evidence for it?

Look at the OpenBSD security advisories in the last 3 years:

* https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

And then look at the same number of security advisories for the Linux kernal during the same time:

* https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

And then remember that NOBODY uses OpenBSD.

Literally no big-time company uses OpenBSD. Who uses OpenBSD??? Literally nobody.

Doesn't the first link list CVEs for the whole system, not only the kernel?

Let's say I want to set up 16 frontend firewall/load-balancers.

In aggregate they will serve/distribute 34 GB/s.

This is a business-critical workload.

Would you put this on OpenBSD? And if so, who would you call when it breaks?

Would you put this on FreeBSD? And if so, who would you call when it breaks?

We put this on Linux. And we can Red Hat when it breaks.

It has broken for us in the past. And we get absolutely top-notch Linux kernel TCP experts on the phone to help us fix the issues in no time.

Who is we?

The fact you have a service contract with red hat is irrelavent to the question of if openbsd is more or less "secure" than linux

I f you need to pay someone as a scapegoat because you break stuff and cannot revert it:

FreeBSD: https://www.xinuos.com

OpenBSD: https://www.openbsd.org/support.html

NetBSD: https://www.netbsd.org/gallery/consultants.html

Oh and load-balancer..Jupiter OS is based on FreeBSD, pfsense and Opnsense(HardenedBSD), Netflix, Cisco, Sophos, Stormshield and so on:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/n...

PS: If you serve 34GB/s you should probably have your own 'top notch' TCP experts ;)

Word? Nobody uses OpenBSD? I reckon you've got some sources to back your claims, right? I mean surely you wouldn't just be making things up. Let's see them.

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

WireGuard: https://en.wikipedia.org/wiki/WireGuard

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.

Enthusiasm noted, but OpenBSD is not Linux.

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

"distros" doesn't only refer to Linux distros, you know :-)

Doesn't it though? The BSD's aren't really distributed using the linux model of multiple distros for the same kernel.

Berkeley Software what?

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.

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?

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

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?

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

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.

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.

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?

I would expect ASIC support no earlier than 2-3 years after the WireGuard RFC is finalized.

I'm not aware of any manufacturer who is committed to providing a ChaCha accelerator or ISA extension, but it seems like it would be highly doable. Not sure what the minimum latency of a ChaCha double round is, seems like it'd be a couple hundred picoseconds, unless there's some sort of forwarding trick with the adders/rotations.

Sure, there is no reason ASICs cannot do Chapoly. I don't know if we ever will.

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.

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.

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

There's a portable userspace implementation written in Go, for places where a kernel driver is unavailable at present.

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...

But the code looks quite different from https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireg...

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.

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.

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.

Might be a good idea to not use the phrase "kernel module" since it means something very specific (code you insmod on linux, kldload on fbsd and so on) which isn't supported on OpenBSD since 2014.

This has nothing to do with the GPLv2 licensing of the code in the Linux kernel.

This is a C implementation that is distinct from the Linux kernel implementation. The most common WireGuard desktop implementation is in Go; the kernel commit is comparing their C WireGuard to the Go desktop WireGuard.

Reply on news.ycombinator.com