HNHacker News
TopNewBestAskShowJobs

zx2c4

7,652 karma · joined May 22, 2011

zx2c4 [1] is Jason A. Donenfeld. President and Security Researcher at Edge Security LLC [2]. Maintainer of WireGuard [3], pass [4], and cgit [5]. Linux kernel developer [6]. Many other projects [7]. Email jason at <username> dot com.

[1] https://www.zx2c4.com/ [2] https://www.edgesecurity.com/ [3] https://www.wireguard.com/ [4] https://www.passwordstore.org/ [5] https://git.zx2c4.com/cgit/about/ [6] https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/ [7] https://git.zx2c4.com/

submissionscomments
zx2c4··on WireGuard for Windows now uses high speed kernel implementation
Security is the top priority. But being useful is also important; if nobody can use it, nobody benefits from that security. Acceptable performance is very important for being useful, especially when tunneling layer 3 packets, where latency has rippling effects. The prior non-kernel WireGuard for Windows simply was not sufficiently useful for real world workloads people wanted to run, because of the lower performance, both on servers and on laptop wifi alike.

A big part of the WireGuard project since the beginning has been trying to figure out how to do high security tunneling that also performs acceptably. It's easy to do one without the other, but doing them both together has meant thinking about a lot of fundamentals, from the protocol state machines on up. It's hard to do tunneling in the kernel at high speed while still maintaining a strong security posture. That's a principal challenge the project endeavors to solve.

More generally, it's worth noting that cryptographers also care about performance quite a bit in things like symmetric crypto. We know well how to make a good cipher now, but making one that also performs at increasingly high speeds remains an open area of research, with whole conferences, such as FSE, devoted to it.

zx2c4··on No Sandbox – Applications That Run Chromium Without the Sandbox
Response from Signal Desktop developer on an insufficient Signal PR I posted a while ago: https://github.com/signalapp/Signal-Desktop/pull/4381
zx2c4··on FreeBSD 13.0
Keepalive fixed in the wireguard-kmod released yesterday and put into ports today:

https://lists.zx2c4.com/pipermail/wireguard/2021-April/00661...

https://cgit.freebsd.org/ports/commit/?id=2ef23d42cbce1ed168...

zx2c4··on In-kernel WireGuard is on its way to FreeBSD and the pfSense router
Which is really the absolute best outcome:

https://lists.freebsd.org/pipermail/freebsd-hackers/2021-Mar...

https://lists.freebsd.org/pipermail/freebsd-hackers/2021-Mar...

zx2c4··on In-kernel WireGuard is on its way to FreeBSD and the pfSense router
I get your point about perceptions, but there's also another aspect of why I found it important and necessary to describe just how poor the code was:

When you're talking about replacing and rewriting the implementation on the eve of release, you better have a good reason for doing so. Stuffing a rewrite of security critical code into the kernel at the last minute is a big red flag. The main question that immediately comes up in that context is, "how is it possible that having a last minute rewrite would be better than the code that was there before? You've only looked at this for a week." And that's a really good and important question.

That much code churn is not something I wanted when I set out to get started with this, but it's ultimately where things wound up. Why? For exactly the reasons I described in my email. The idea wasn't to be _insulting_, but rather to accurately and vividly describe the state of the code, as a motivating factor for the rewrite. I see how perceptions could view that instead as denigrating, but that wasn't really the motivation. And it's not as though anybody really is rushing to defend that code either; it doesn't take a lot to look at that and make up your mind that it was probably unfinished stuff, not coded with much love, that was committed prematurely.

It also had the, I think, positive effect of leading to more scrutiny of the review process. A few people have piped up and mentioned to me that their concerns during that review weren't addressed. And as a consequence of everything, all of the code, including the rewrite, is being removed from FreeBSD until it can be carefully examined and completed, which is really the best of conclusions.

zx2c4··on ECC matters
Voila http://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinabur...
zx2c4··on Maps.me is gone, and we must bring it back
https://www.compart.com/en/unicode/U+0336
zx2c4··on OpenBSD 6.8 released (OpenBSD's 25th anniversary)
Yup! Pretty exciting indeed. Now OpenBSD has first class support for WireGuard, out of the box. And all the usual tools such as wg(8) and wg-quick(8) work too.
zx2c4··on Q3 Linux touchpad update: Multitouch gesture test packages now ready
> Edit: I'm using a Thinkpad P1 Gen2, a top-tier recent-gen workstation laptop, and this is a big enough problem where it's forcing me to use X11 on Ubuntu 20.04.

I'm also on a P1gen2. I just added support for the Trackpoint/Thinkpad through the more advanced RMI4 interface in the kernel, instead of going through PS/2 emulation mode:

https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.g... https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.g...

This will be in Linux 5.10 and should improve things quite a bit.

zx2c4··on AMD PSB Vendor Locks EPYC CPUs for Enhanced Security at a Cost
Regarding Raptor...

https://www.talospace.com/2020/08/power10-sounds-really-grea...

https://www.talospace.com/2020/07/condor-cancelled.html?m=1#...

Were there ever any updates to that rather pessimistic blog post?

zx2c4··on Modern C
I don't use Github much. My code is mostly on https://git.zx2c4.com
zx2c4··on WireGuard support in Mikrotik RouterOS v7.1beta2
This repo appears to use Lochnair's old builds, which are unmaintained/deprecated and replaced with the official ones linked to by GP.
zx2c4··on WireGuard support in Mikrotik RouterOS v7.1beta2
And it was backported to 18.04 and 16.04. And the Debian backports kernel. And SUSE enterprise. And... So indeed GP's comment isn't totally accurate.
zx2c4··on WireGuard support in Mikrotik RouterOS v7.1beta2
Actually, WireGuard has first class support now on a large number of distros, without the need for any additional compilation: Ubuntu 16.04, 18.04, 20.04, Fedora, Debian, OpenSUSE, Arch, Mandriva, Alpine, Nix, Void, OpenWRT, and others. Check out www.wireguard.com/install/ for the whole list.
zx2c4··on Tinc – A Virtual Private Network (VPN) Daemon
Here's where we're at with WireGuard distro kernel shipping support, as of writing (July 4, 2020):

- Ubuntu Focal 20.04 LTS: native built-in

- Ubuntu Eoan 19.10: native built-in

- Ubuntu Bionic 18.04 LTS: native built-in

- Ubuntu Xenial 16.04 LTS: dkms :(

- Ubuntu Trusty 14.04 LTS: dkms :(

- Debian: native built-in

- Fedora: native built-in

- Mageia: native built-in

- Arch: native built-in

- OpenSUSE: native built-in

- SUSE Linux Enterprise: native built-in

- Alpine: native built-in

- Gentoo: native built-in

- Exherbo: native built-in

- NixOS: native built-in

- RHEL/CentOS: dkms and elrepo kmod :(

- Void: native built-in

- Adélie: native built-in

- Source Mage: native built-in

- Buildroot: native built-in

The rule of thumb here is: distros with kernel ≥ 5.6 have it native built-in, plus a few distros that have backported it, like Ubuntu, Debian, and SUSE. I'm in the process of working with other distros to get it backported; we'll see if I'm successful. I'm also maintaining a 5.4.y backport for distros who ship this LTS kernel (like Oracle's UEK), to make backporting it easier: <https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y>. There are instructions for each distro on <https://www.wireguard.com/install/>.

If you're presently having "update troubles", make sure you're using the latest variant of any of the "native built-in" distros written above.

zx2c4··on Show HN: Runc – Compile and run C in one command
Another take on the same idea: https://git.zx2c4.com/cscript/about/
zx2c4··on WireGuard Merged into OpenBSD
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.
zx2c4··on WireGuard Merged into OpenBSD
WireGuard project announcement is here: https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588...
zx2c4··on Duff's device
I used one of these for the implementation of Siphash in the Linux kernel, if you're interested in a real world example: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
zx2c4··on NextDNS is my new favourite DNS service
A lot of people who erroneously turn on PersistentKeepalive on their phones wind up with battery drain for clear reasons. Mobile phone users very much should not be using PersistentKeepalive.
zx2c4··on WireGuard 1.0 for Linux 5.6
Your first point: There's no part of WireGuard that inherently demands the use of a static IP address. You can run whatever dynamic IP protocol you want inside of it or outside of it. The entire interface configuration is dynamically configurable at runtime. We're working on one called wg-dynamic, but others have done others.

Your second point: Obfuscation protocols can encapsulate WireGuard just fine.

zx2c4··on Private Internet Access Announces WireGuard VPN Beta
I'm the Donenfeld in question. I have not worked on PIA's implementation at all, nor have I seen any of its source code. I've chatted a bit with their developers online and offered some tips here and there about where to find the right wireguard source code and things like that, but that's about it. The original version of this post vastly and inaccurately overstated my involvement.
zx2c4··on San Jose: Three TSA agents test positive for Covid-19
https://en.wikipedia.org/wiki/Covenant_Aviation_Security

Thanks! Never knew that this role was sometimes contracted out.

zx2c4··on San Jose: Three TSA agents test positive for Covid-19
Going through SFO on Sunday, the TSA agent working the controls behind the X-ray screen sneezed into his hands. A colleague looked up at him, and then he sheepishly ceded his seat to the other agent and put on new gloves. As I was packing up my things on the other side of the metal detector, I saw him chatting with a more managerial looking TSA agent. Not sure what conclusion to draw from the brief observations, but it did leave an impression.
zx2c4··on macOS Kernel Extensions are officially deprecated
What program are you using that relies on net.sf.tuntaposx.tun? macOS has had their own utun driver since a long time.
zx2c4··on Ubuntu 20.04 LTS Adds WireGuard Support
WireGuard by now is a several-years-old codebase that has seen quite a bit of deployment, thanks to our compat layer for older kernels.
zx2c4··on Ubuntu 20.04 LTS Adds WireGuard Support
Yea, kernel-wireguard on Android is just for people who have rooted their phones and want a little extra adventure. Cellphones have weird networking stacks and unusually written drivers (I'm looking at you, qcacld and rmnet_perf...), so supporting WireGuard's kernel module on Android has been very worthwhile to us for fine tuning things. Plus the performance is as good as can be in kernel space. But it's definitely something for "rooters only."
zx2c4··on Ubuntu 20.04 LTS Adds WireGuard Support
For Google Pixel devices, we're actually prebuilding and distributing WireGuard kernel modules for use in that app:

https://github.com/WireGuard/android-wireguard-module-builde...

zx2c4··on Ubuntu 20.04 LTS Adds WireGuard Support
Actually, that's not even relevant. For the last several years, I've been developing WireGuard on top of the latest kernel from Linus, while maintaining a "compat" layer to seamlessly backport it using horrendous tricks with the C preprocessor. That's allowed me to keep the codebase clean and ready for mainline Linux, while enabling people to use it on all the old kernels. I've maintained this backport layer for every kernel since Linux 3.10, including the RHEL-7 and RHEL-8 ports. This has been quite a lot of ugly work, but ultimately worth it as its given us enormous amounts of testing in odd environments, so what's shipping now in Linux 5.6 is rather polished, as opposed to being brand new and untested. We maintain some CI for this, too, testing lots of kernels and architectures. Scroll down to the "wireguard-linux-compat" section of https://www.wireguard.com/build-status/ to see.

All this is to say that there's not really much work that needs to be done by Ubuntu or RHEL or anyone else that wants to ship WireGuard -- the backporting stuff has already been done and is fairly widely deployed by now.

zx2c4··on Ubuntu 20.04 LTS Adds WireGuard Support
Right, that's the plan.
← PreviousPage 3 of 21Next →