WireGuard in FreeBSD | Hacker News Reader

WireGuard in FreeBSD

cgit.freebsd.org

238 pointsnixcraft78 comments

Between the FreeBSD WireGuard drama and WireGuard's maintainer's (Jason Donenfeld) reaction to the NetBSD implementation, I think it's a good idea to look at not only what's happening, but why and by whom. There's something slightly fishy about it all.

https://mail-index.netbsd.org/current-users/2020/08/20/msg03... https://mail-index.netbsd.org/current-users/2020/08/22/msg03...

Jason Donenfeld has, to this day, never answered direct and simple questions about WHY he felt so strongly that NetBSD's wg implementation should be removed from NetBSD.

>FreeBSD WireGuard drama

Can you fill me in? I experimented with Wireguard a while back but it's been a few.

(It sounds like concern about design choices not... gossip? Infosec has been insane the past fourish years.)

The original implementation had a lot of issues, but more importantly it was pushed to head and deployed in production without a review:

https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...

This is a lie. The bad code was never "deployed in production", it was pulled before a release. FreeBSD users were never exposed to it. HEAD code branch is where reviews happen in BSDs, this code failed that review and was removed.

It’s also a lie that it wasn’t available for review. It was in review for about 10 months before it started to land in a release.

How about you provide links that backup your claims.. It's well documented that you'll go to great lengths to act in bad faith and make nonsense claims on the internet.

https://www.wipo.int/amc/en/domains/search/text.jsp?case=D20...

https://opnsense.org/opnsense-com/

https://reviews.freebsd.org/D26137

It looks a lot like that was landed without completion of a proper review, and with several changes made without any review. I appreciated Netgate's commitment to improve the FreeBSD operating system, and to build the pfSense product. It's the attitude of Netgate's team, where an opportunity to offer a mea culpa and move forwards with the expertise of a core FreeBSD developer/maintainer and the subject matter expert was presented, was instead met with open hostility. It made it appear as if getting it done was more important than getting it right. Sometimes we get things wrong, we put a lot of work into code that we're proud of, then our project manager and peers come along and absolutely tear it down and rebuild it. It's an opportunity for growth, not a waste of effort or money.

I'm glad things improved and that you guys brought on Christian McDonald.

It was released to production by Netgate in pfSense. That's why they threw such a hissy fit over it when the code quality was revealed and blew up publicly.

A a larger backer and contributor to freeBSD pushed wireguard kernel mode support out in one of their production releases and then slowly walked it back. Whether freeBSD likes it or not, this sort of thing reflects poorly on freeBSD as a whole when a large donor/backer and contributor that advertises freeBSD then releases something that is a pile of half baked shit.

https://www.netgate.com/blog/wireguard-removed-from-pfsense-...

https://lists.zx2c4.com/pipermail/wireguard/2021-March/00650...

I once deployed linux-next in production, it reflects poorly on linux.....

But yeah dont use pfsense but opnsense...but everyone should know that already....right?

https://news.ycombinator.com/item?id=30719403

Thanks for the background. However, I believe your question

> Jason Donenfeld has, to this day, never answered direct and simple questions about WHY he felt so strongly that NetBSD's wg implementation should be removed from NetBSD.

gets answered by Jason:

> In its current form, there are implementation flaws and violations that I do not consider acceptable, and deploying this kind of thing is highly irresponsible and harmful to your users. Rather than playing never ending whack-a-mole misery with this -- which is not a path I'm willing to go down here -- I'd like to re-examine how this is built from the ground-up and do some serious code study.

(This response of his is corroborated by the article https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice... which someone else posted further down.)

He also mentions that he's not against having a WireGuard implementation included in NetBSD in general.

What about that describes why it should not be implemented? All he says is "I don't like it and it is not acceptable". If you write a paper and have it proof-read by many competent people, then hand that paper in to a teacher and get back an F with "This is no good, it has flaws I do not consider acceptable", would you think that was reasonable explanation for failing your paper?

1) That's not at all what he said. 2) In his message he also mentions that he is short on time and would be willing to elaborate on why the code is flawed as well as collaborate on getting a polished implementation of WG into the kernel a week later. 3) As mentioned by the article I linked, he did follow up on his promises: https://lists.zx2c4.com/pipermail/wireguard/2021-March/00649...

1) What isn't what he said? I paraphrased you and you quoted him

2) Short on time doesn't correlate with writing up three long replies all refusing to mention even one specific technical problem

3) Your link is in regards to FreeBSD and OpenBSD, and does not mention NetBSD, which is what we are talking about specifically.

The message you link to is in regard to the FreeBSD implementation and not NetBSD.

If anyone wants to review the NetBSD implementation, see:

https://github.com/NetBSD/src/blob/trunk/sys/net/if_wg.c

NetBSD just needs Rust support for kernel dev. ;)

I appreciate when folks take a reasonable stand against craptastic software engineering practices (cough OpenSSL cough) and insist on quality code.

I may be wrong but openssl was never deemed poor quality primarily due to the devs not giving a damn but because of legacy code and lack of funds.

He never stated any technical reasons at all - neither then, nor a week later, nor since. He was asked very specifically, by people who are extremely competent, on a technical list:

"Can you be specific about what is wrong?"

"I don't like it" isn't good technical reasoning.

I kind of understand him, WireGuard is connected to his Name, if a implementation is not matching his taste of quality (i especially used taste here) and something happens it backfires.

It's a bit the same as with pulse-audio in the beginning, where it backfired to poettering even if the code was not finished and the distributions, especially ubuntu integrated it pretty bad, told no one that it was alpha...and everyone was like:

What bad thing my sound worked with alsa before...i hate pulse-audio, poettering destroyed the "year of linux-desktop", now i hate him too ;)

The "why" is IMHO simple if you look at the pattern: they didn't ask him for advise. I guess he really expects this. While I personally find this attitude/his comments in different places a bit toxic, he has unfortunately been proven right in the past (like in the freesbd case). I guess it sometimes just requires such people to something right with just enough rigour. I am also be really thankful for this beautiful bit of software in such a messed up space. However, I also totally understand the people who have not asked for his opinion before releasing (I guess this can be a downside).

Good post from Phoronix on the topic, also giving a bit of context as to why they're "bringing back" the driver: https://www.phoronix.com/news/FreeBSD-WireGuard-Lands-2022

I don't know what is good about this post. The ars technical post linked in another comment really sheds some light on to this.

I mean, at the time of the merge, the Phoronix post seemed to be the only one that gave a quick rundown of the whole "saga", with links to posts covering the relevant news from 2021.

I'm really looking forward to this making its way into OPNsense and such.

I'm already running the kmod Wireguard on Opnsense unless I'm missing something?

for me OPNSense is installing the go implementation when installing via the plugin system.

Maybe there was a time it was using the old kmod port?

You can manually install the kmod and the plugin will that instead of the go implementation.

I have a Dutch physical OPNsense (business license) box with 10 GbE ports. IIRC, it's the userland version. To be honest, I prefer most things to live outside of the kernel than use it as a kitchen sink dumping ground for "but but but it's faster!".

I am using the kmod, you can easily switch.

https://www.reddit.com/r/opnsense/comments/wa6xil/opnsense_2...

I believe the current opnsense version runs in userspace and has no kernel support.

I am using the kmod, you can easily switch.

https://www.reddit.com/r/opnsense/comments/wa6xil/opnsense_2...

Genuinely curious…

Is there any security benefit to moving a WireGuard bastion from fully patched Ubuntu to FreeBSD?

Generally, I would trust the defaults of FreeBSD more than the defaults of Ubuntu, but FreeBSD may require more setup of any utilities you might be using. But, I don’t actually know for sure.

I plan on using FreeBSD bastions.

The "<x>BSD is more secure by default" argument always falls very flat to me. In addition to being completely unsourced and unsupported (who ever links to a study when they make this claim?), even if it is true, once you've configured your BSD box for use, you're pretty far from the default so I'm not really sure what the claim is even supposed to say.

Its fine to like BSD, I just wish people were willing to be honest any say it's based on their personal and philosophical preferences, rather than based on any objective metric.

I think the claim might be related to openbsd's claim on their website:

> Only two remote holes in the default install, in a heck of a long time!

https://www.openbsd.org/

I remember a time when it was zero, not two.

This isn't really the right place to launch into a full diatribe on this, but for anyone who isn't familiar and may be confused by this claim, I want to point out this specifically refers to the default install with no extra services running.

I love BSD based OSes, but I've always found this claim to be a little irritating, because it's far less impressive IMO than it sounds to the uninitiated. It's impressive from the perspective of Windows or Solaris which enable huge numbers of network daemons by default and have both suffered numerous high profile remote vulnerabilities on default installs, but OpenBSD isn't really much different from most Linux distros on this. I'm sure most distros have had more remote vulnerabilities, but not that many. Your average Joe out-of-the-box install of Fedora or Ubuntu doesn't really have any open services IIRC, so an exploit would need to directly target the Linux IP stack, or one of the network autoconfig services if that's in scope.

This is all correct, but in my not so humble opinion all the BSDs profit from having a more compact and cohesive base, which leads to less cognitive load for the sysadmin. Which you can learn and understand without having to resort to searching crack overflow, or whatever else, if you're so inclined. Which in turn can lead to a better understanding of the 'big picture', and the additional services running atop of it, no matter if they are coming from the base, or have been added afterwards. Not necessarily, but it eases the path to that sort of mindset.

I don't see that in any mainstream Linux distribution. There are alternatives, but then you're more or less on your own, necessitating work which could be avoided if some BSD satisfies your needs regarding hardware driver support.

At the end of the day it amounts to https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

I'm a grumpy old fart and (usually) don't like chaos.

A minimal Debian installation (which is easiest to do from the netinstall image, although it can be done from any other by selecting the appropriate option in the installation menu: https://unix.stackexchange.com/a/615465) gets you the most slimmed down system possible without going to something like Alpine. There's nothing to remove there if you want your system to boot at all.

No idea why it's not more popular tbh (I setup most systems this way both for security and efficiency reasons). The default installation profiles for most distributions are incredibly bloated in comparison (especially Ubuntu and such).

Dude, I know that screen, I also did the textmode equivalents ;-)

Nevertheless any Debian or derivative feels bizarre to me. Yes, I know apt-pinning, custom repos and whatnot.

I'm writing this on a derivative booted into 'ramdisk' and running from there for 139 days now. (Oh my Gawd! How dare I?!) Because the good folks from AntiX and MX-Linux made it possible, and did the work for me. Making intelligent use of the facilities Linux can offer.

apt-shred dist chainsaw!

I really desperately want to agree with this at an emotional or aesthetic level - I ran NetBSD on my laptop for the largest portion of my teenage years, using FreeBSD on an old poweredge server for all my "needs a ton of RAM" programs. I had been on this quest to "truly understand" computers/OSes since prepubescence, and BSD appealed to me for exactly the reasons you describe - the pieces just seemed to fit together better.

I've gone deep down this rabbit hole, but now in my mid 20s, it seems like it's all sentimental - the amount of time I interact with any base system is pretty low, Linux's device model seems better suited to modern systems than BSD's more static kernel configs inherited from PDP-11/VAX/VMEbus-esque systems, and probably more than anything else, it's almost always easier to get your software to run on Linux. And after thinking about it, isn't that really the purpose of an OS? To facilitate running and developing software?

I still love running NetBSD on my 90s SPARC laptop, with device drivers descendant from the original 4.4BSD from UCB. I've gone so far as to patch my local install to get the crappy mu-law audio output working so I could playback youtube videos on it for kicks and giggles (recent releases overhauled the audio driver backend and the AMD7930's driver doesn't release some mutexes, failing asserts and hard faults the kernel)

Sometimes the Cathedral isn't so nice though. I never really figured out where I could send the ~5 line patch for this, only where I could submit a bug report, and possibly start a dialogue on the mailing list where I could maybe suggest the fix, and then a NetBSD developer could go fix it themselves? Didn't think it was worth the effort, so I never patched it.

Meanwhile, on Linux, I got a one line patch into the kernel, fixing a presumption that all 32-bit processes are big endian on PowerPC, thereby allowing the development of a 32-bit LE userland. Almost certainly useless to anyone, but it was a bug fix, and the patch process was fairly painless.

I think the end result is that Linux is fast and messy and a little ugly, but most of my hardware and software is also ugly and messy. I could run BSD on my laptop nowadays, but the only day-to-day change to my display server running firefox and $TERM windows would be a hotter keyboard and a few cents added to my energy bill, since those kernels don't really vibe with Intel p-states or whatever it's called now. My userland environment and day to day life is basically identical, just a few added problems when some piece of software assumes I'm on Linux and breaks.

Well, that and OOM handling. I don't ever remember the BSDs locking up quite like Linux does when it runs out of memory (or thrashes swap).

This turned out more rambly than I intended, but oh well. While I'm ranting, why is OpenBSD's fdisk the only implementation of fdisk with a command mode where quitting automatically saves changes*, as opposed to util-linux's fdisk, and NetBSD/FreeBSD's fdisk which always prompt? :-)

FreeBSD does use modern Intel pstates, for what it’s worth.

One might well ask why a default redhat install doesn't have a dozen services running and when did that become the standard?

It became the standard _because_ of OpenBSD! They mocked others for decades. People forget that!

I remember SuSE 6 from me youth. It run of the box (having selected a Desktop-Setup) SSH, Telnet, Apache, FTP, Finger, Samba, CUPS and probably other daemons I forgot! You dail-in to the internet and bam: everthing/most was accessible via a public IP. I used to "pwn" boxes with exploits from packetstorm myself.

(Ironically OpenBSD was late to the "easy update"-party. You used to need to patch and compile updates yourself.)

This is untrue in my experience.

I've used FreeBSD a fair bit in the past and Ubuntu and Debian more continuously. Unless something radically changed recently. My experience is about 6-8 years old now but FreeBSD requires a lot more configuration when setting up common services, whereas Ubuntu and even Debian have good defaults that you can usually bring up without having to first consume the entire manual for that service.

There's probably a reasonable sounding argument buried behind this like "you cannot run a service securely if you do not fully understand the configuration first." but in practice this just results in poor initial configurations because it takes time to fully understand all of the knobs of configuration on a service.

FreeBSD can be a solid system, but it's less practical in many ways for reasons like this.

This is untrue in my experience.

I was using FreeBSD as my desktop for almost 15 years, since the 4.1 times, and the amount of work it took to make some sane vpn client out of an ubuntu is nowhere near what I had as my griefs with FreeBSD back then. Not even mentioning pf vs iptables and how 20(?) years passed before linux had something comparable like nftables.

Nowadays it's mostly fine, but..

Case in point : I had to write and contribute wireguard support to the netplan to make it marginally sane.

I sense that we might be basing our conclusion on qualitatively and temporally different things.

My limited experience with FreeBSD was as a desktop and server for a few years around 2009ish to 2012, but also as a basic user of basic services. From memory a lot more hoops had to be jumped to get equivalent things working on FreeBSD, and I was always left with a nagging feeling after initial setup on FreeBSD that I didn't yet know enough to feel confident in the configurations I had produced, compared to Debian and et al at the time, where configuration felt like they left the bare minimum for you to customise, and working defaults for the rest that you could gradually learn to tweak without the pressure of getting every variable correct from the get go.

However as a user who already thoroughly understands the service or it's domain I expect this kind of detail may be lost... instead you can compare based more on the flaws of the configurations and their implementations (which I suspect applies to your experience). But for the rest of us it results in flaky custom initial configuration. It's the same for me if I pick out a piece of software now that I have become very familiar with and already know how to configure inside out - i wouldn't experience the same kind of problem that someone unfamiliar would.

To clarify, I guess I'm talking about sane defaults from the perspective of new users, poor defaults combined with new users can end up with insecure or problematic results - even if the default configuration alone is technically fine.

I expect Linux and FreeBSD and other BSDs have likely improved a lot over the last decade from either perspective anyway.

IMHO: No. If you like the Ubuntu userland, I see no reason to switch.

there are no open CVEs against the default install of wireguard on Ubuntu. for all the grief ubuntu gets i find their server has very sane defaults.

  $ openssl version
  OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

Until the 1st?

My server is 20.04 and it’s 1.1.1f. I would think most people aren’t on 22.04 yet as that’s still pretty fresh for a server.

Wireguard doesn’t use openssl.

In short: no.

no, there might even be detriment Because of the way FreeBSD modifes openssh. OpenBSD might be an improvement to Ubuntu security wise.

No openssl:

https://www.wireguard.com/papers/zinzindohoue-bhargavan-prot...

I meant in the context of a Bastion ssh server, which is what the patent meant i think.

Then just exchange the ssh-server with one in the ports, compile it with wolfssl, openssl-(devel?), libressl or mbed TLS, whatever you want. The stuff in base is meant to be compatible and as slim as possible (for example the kerberos-server in base).

Or define the runtime options from the base-ssh-server in rc.conf (that's what i normally do):

sshd_enable="YES"

sshd_dsa_enable="NO"

sshd_ecdsa_enable="NO"

sshd_ed25519_enable="YES"

sshd_rsa_enable="NO"

If you want RSA=YES then you probably/maybe want to delete all moduli less then 4096.

https://github.com/bsdlabs/ssh-hardening

Can someone please explain: I've been using WireGuard via `wg-quick` command in FreeBSD for quite a while now. What does this commit do?

It adds wireguard support to the kernel.

Okay, but... what difference does it make? Apart from not having to install it manually? Am I missing something?

I believe moving wireguard support into the kernel reduces context switching for the app and greatly improves performance.

Wireguard in the kernel is faster than the userspace implementation. You still have to install the tooling.

If I recall correctly, we went through this on Linux in the past. I believe the first wireguard implementations were userspace while the work was being done to get it in the kernel.

As others have hinted to -- no userspace copies. No context switches. Vroom Vroom.

It depends on how you were running before -- if you had the wireguard-kmod package, then yes, the only difference is that you don't have to install it manually. If you only had the wireguard-go pkg before, then see the other responses where you'll now be using the kernel implementation instead of userspace.

edit to note: we can't really provide wg-quick in base at the moment (uses bash-isms), so that still ends up needing installed manually if wg(8) isn't sufficient for your needs.

I care about this only in the context of OPNsense which I replaced my old pfSense router with. Though I'd love to run a linux firewall router rather than *BSD, none seem up to the task. OPNsense is good.

I'm currently running a VM with a wireguard server within my firewall. That VM is running linux. I'm fine with this until the kmod lands in OPNsense, then I'll likely transition. One less VM to manage sounds good to me.

And another plug for OPNsense. Setting it up was easy. Far easier than pfSense, which I'd used for about a decade.

I use WireGuard on OPNsense (FreeBSD-based router appliance) and clients on macOS, iPhone, iPad, Android, Linux, and Windows. It's easy to setup and Just Works(tm). Throw away your AnyConnect, Tunnelblick (OpenVPN), and such.

I assume this is with Jason Donenfeld's approval?

It came from his git server so I’m assuming so.

> Obtained from: git@git.zx2c4.com:wireguard-freebsd @ 3cc22b2

Jason open sourced the project. Why would they need his approval?

https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...

So its about technical guidance, not approval to include code. Got it.

WireGuard is a registered trademark.

This puts reasonable restrictions on the usage of the term WireGuard to name your alternative implementation, but neither prevents other people (without any approval) from implementing the protocol nor even from using the term WireGuard to (correctly) describe or label the protocol implemented (and I even could see a solid argument that any command line tooling that might be expected to be compatible with existing third-party tooling that calls out to said tools should be allowed to use the term "wg" or "wireguard", given prior legal precedent that if you use a trademark in a place where it causes a compatibility issue you cannot attempt to claim infringement of that trademark to later stifle interoperability with your project; but, if you go down this path, I'd highly recommend consulting an actual lawyer and getting your response ready to any complaint).

Yes! Very excited by this. We developed this together out-of-tree, and it's been available in ports (FreeBSD's package system) for a while now. This here is about moving it into the FreeBSD base system, so that it'll now be developed and improved alongside the rest of the operating system. Terrific step forward.

Reply on news.ycombinator.com