LWN: Comments on "WireGuarding the mainline"

WireGuarding the mainline

marcH — Sun, 19 Aug 2018 16:16:34 +0000

Not sure what you mean by "build" but I believe there is a number of micro kernels already, some of them commercially successful.

WireGuarding the mainline

marcH — Sun, 19 Aug 2018 16:04:35 +0000

https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing)

WireGuarding the mainline

mjg59 — Sun, 19 Aug 2018 07:51:51 +0000

It depends on what your threat is. Full control of network traffic is certainly bad, but doesn't necessarily break assumptions. Being able to compromise the entire kernel does.

WireGuarding the mainline

Cyberax — Sun, 19 Aug 2018 07:35:34 +0000

But they'll be able to modify the DNS traffic and/or mount MITM attacks. Never mind good old sniffing. If this happens on a web-server then it's actually probably enough by itself.

WireGuarding the mainline

mjg59 — Sun, 19 Aug 2018 07:12:49 +0000

Eh they're not able to escalate that into something that modifies the on-disk bootloader such that the compromise survives reboots

WireGuarding the mainline

Cyberax — Sun, 19 Aug 2018 04:08:15 +0000

Microkernels are not inherently more secure.

For example, you move networking out of the kernel space. Now if somebody compromises the IPSec parser, your kernel will survive unscathed. Of course, all your network traffic will now be compromised but who cares? After all, there's not much an attacker can do if they control all the traffic, including domain sockets possibly used to send secure messages.

WireGuarding the mainline

mgb — Sun, 19 Aug 2018 04:02:02 +0000

> To anyone not blinded by theory, keeping the kernel as FAST as it can get is a priority. This is actively hindered by theoreticians fixated on micro-kernels.

For many applications security is more important than performance.

For many applications a major increase in kernel performance results in only in minuscule improvement in overall performance.

For the same amount of effort a smaller kernel is likely to be more secure than a larger kernel.

WireGuarding the mainline

Wol — Sat, 18 Aug 2018 23:12:45 +0000

> keeping the kernel as small as it can get

To anyone not blinded by theory, keeping the kernel as FAST as it can get is a priority. This is actively hindered by theoreticians fixated on micro-kernels.

(NB - I said *a* priority, not *the* priority. In engineering, everything is a trade-off and small may not be beautiful at all ...)

Cheers,
Wol

Kernel IPsec implementation

Cyberax — Sat, 18 Aug 2018 09:03:12 +0000

This is not unique for Wireguard. IPSec works in exactly the same way.

Kernel IPsec implementation

jengelh — Sat, 18 Aug 2018 08:40:08 +0000

https://commons.wikimedia.org/wiki/File:Netfilter-packet-... has a (packet filter centric) view of the things that roughly happen. If you draw the crypto loop openvpn-style between "interface output" (tun0) and "local process" (other side of tun0) instead, then there are a handful of diagram boxes that necessarily get an additional execution before your packet leaves out eth0. And some people just wanted to do without that performance reduction when KLIPS/tun was replaced with Netkey IPsec/xfrm.

WireGuarding the mainline

aigarius — Wed, 15 Aug 2018 14:58:46 +0000

If the point was to provide a simple crypto API ... why not just do that? Provide a simplified API, but then implement it using the existing kernel crypto system. You get both a simple and a comple API, hardware acceleration and easier path to merging it all.

WireGuarding the mainline

zlynx — Fri, 10 Aug 2018 20:15:19 +0000

If you're going to have file systems and networking in the kernel _at_all_, then putting the encryption for those into the kernel is a requirement.

If you want a micro-kernel then build a micro-kernel.

WireGuarding the mainline

lnnuser21821 — Fri, 10 Aug 2018 12:46:44 +0000

Look, I don't mean to start a holy war, but the kernel should still be moving in that direction. To anyone not blinded by sunk cost fallacy, keeping the kernel as small as it can get is what we should be looking for, not extending potential for more privilege escalations.

WireGuarding the mainline

ndesaulniers — Fri, 10 Aug 2018 07:45:26 +0000

To add to this (maybe not average Linux desktop distro's), Google has a strong policy on encrypting data in flight or at rest. The filesystem is encrypted on Pixel phones, and servers in our datacenters. Both have some form of hardware acceleration for encrypting many blocks worth of data.

WireGuarding the mainline

ndesaulniers — Fri, 10 Aug 2018 07:41:10 +0000

"Remind me why we have a monolithic kernel and not a microkernel?"

Networking subsystem and file systems absolutely can be moved to userspace. Userspace can than link against 9 different implementations and versions all with different bugs.

WireGuarding the mainline

lnnuser21821 — Thu, 09 Aug 2018 20:50:39 +0000

Remind me why the kernel needs a crypto library instead of just having it in userspace again?

Kernel IPsec implementation

zlynx — Thu, 09 Aug 2018 17:18:49 +0000

When I used to run IPsec it was at the border gateways, so I never had to use UDP encapsulation. That would make it trickier I suppose.

Kernel IPsec implementation

rweikusat2 — Thu, 09 Aug 2018 14:54:24 +0000

Minor error in here: "Decapsulated reply traffic" make no sense.

Assuming there's a VPN server to which clients connect which utilizes some internal network 'through' a set of ESP tunnels and also acts as NAT gateway to the outside world for clients, the ESP/ ESP-in-UDP traffic, the incoming traffic on the internal network and the incoming and outgoing traffic from the external address of the gateway can be captured but not the reply traffic on the internal network (logically) originating from the internal address of the gateway and destined for the internal address of some client as that's transformed according to the rules in the SPD before anything outside gets a chance to look at it (AIUI).

Kernel IPsec implementation

rweikusat2 — Thu, 09 Aug 2018 12:47:25 +0000

Encapsulated datagrams either use IP protocol 50 or UDP and port 4500, filtering to exclude them or to look exclusivey at them is not more difficult than excluding ARP, SSH and STP and whatever other uninteresting/ noise traffic happens to appear on some interface.
What's more of an actual problem is that decapsulated reply traffic usually isn't visible in tcpdump output (it's entirely conceivable that I just don't know how to make it visible).

But I was still making a statement about the code, so why did your "I want to talk about something entirely different" text get attached to that?

Linux IPsec also supports so-called "route-based VPNs", BTW.

Kernel IPsec implementation

rweikusat2 — Thu, 09 Aug 2018 12:28:40 +0000

That's usually not going to help because one will usually encounter ESP in UDP encapsulation so that NAT-T is possible.

Kernel IPsec implementation

zlynx — Thu, 09 Aug 2018 04:20:13 +0000

It's been a while for me, but I recall that IPsec packets have protocol 50 while UDP is 17 if you want to separate them.

Kernel IPsec implementation

luto — Thu, 09 Aug 2018 00:32:54 +0000

I actually strongly dislike the Linux implementation. I have never looked at the code, but the fact that the encapsulated and plaintext packets are on the same interface makes using Wireshark or any other packet capture tool miserable. And getting firewall rules right is interesting at best.

WireGuarding the mainline

zx2c4 — Wed, 08 Aug 2018 18:25:24 +0000

Yes and yes.

WireGuarding the mainline

lbt — Wed, 08 Aug 2018 18:06:11 +0000

Does that assembly cover a variety of architectures?
Is there fallback to C?

Kernel IPsec implementation

rweikusat2 — Wed, 08 Aug 2018 17:26:10 +0000

There's a Linus Torvalds quote in the text:

Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

I can't comment on OpenVPN but I can comment on the Linux IPsec implementation and this comment would be "This is a reasonably organized and well-structured piece of code I could understand and change [to suit some specifc needs, eg, migrating IPv4-based IPsec SAs etc to different IPs/ ports if a client address changes] fairly easily". The kernel does contain much worse things, examples I'm somewhat familiar with (due to other work) are UNIX domain sockets and the USB handling code.

I also don't think the "the IPsec-specifications" are overly complex and difficult to understand but I admit that I've been working on a proprietary fork of an open source IKE implementation for years which might have helped here. But that's a different conversation.

Kernel IPsec implementation

storner — Wed, 08 Aug 2018 14:14:43 +0000

From my understanding there is not so much criticism of the kernel IPSec implementation. It is the entire design of the IPSec specifications that is seen as "wrong", in the sense that they are overly complex, difficult to understand and implement, and implementations are - for all practical purposes - impossible to review for security issues.

And since IPSec was designed many moons ago, it also carries a lot of cruft - but you cannot dump it because that would break interoperability between implementations.

Wireguard is a fresh start on designing a VPN. Sometimes the best solution really is to start from scratch.

Kernel IPsec implementation

rweikusat2 — Tue, 07 Aug 2018 19:03:55 +0000

I did some work on the kernel IPsec code in the past (added a few features needed for a particular product) and compared to other parts of the kernel I've also worked on, eg, the AF_UNIX socket implementation or some of the USB code, I didn't think it was that bad.

WireGuarding the mainline

luto — Tue, 07 Aug 2018 15:26:45 +0000

I encountered some of this while doing VMAP_STACK. The existing crypto APIs support for doing crypto on small stack buffers is mediocre, to put it mildly.

WireGuarding the mainline

zx2c4 — Tue, 07 Aug 2018 15:16:16 +0000

It's a bit more than cut&paste -- we worked on that assembly quite a bit. But indeed the vast majority of the patch is optimized assembly, which tends to be, well, long.

WireGuarding the mainline

ms-tg — Tue, 07 Aug 2018 13:20:21 +0000

> ...the Zinc portion will be considerably different in form for v2. Split into several separably reviewable parts...

As others have said, *Thank You* for what you are doing!

Do you think, at the end of the Zinc v2 patch series, there will be the patches that refactor the existing crypto subsystem to use the new Zinc as the default non-accelerated implementation, removing all existing non-accelerated implementations outside of Zinc, and then keeping the existing crypto acceleration features as a layer on top of Zinc?

Super interested to see, as a "natural experiment", if that level of refactoring and unification across subsystems can really occur in the current kernel development process in a situation like this?

Thanks,
-Marc

WireGuarding the mainline

corbet — Tue, 07 Aug 2018 12:19:15 +0000

Apologies if the, let's say, "language favored by LWN editors" raised some hackles of its own; obviously you weren't out to upset people. The "significant improvement" part seems to be getting across - looking forward to having all of this in the mainline.

WireGuarding the mainline

kaliszad — Tue, 07 Aug 2018 09:54:23 +0000

Thank You for Your hard work.

I have been in Your talk at 34C3. As I said after it, I would very much like to use WireGuard with some kind of failover like VRRP/ keepalived or Pacemaker. I guess, this is a harder problem, than it looks. You have to move the virtual IP to the node (that is easily done) but the problem is to turn the interface on in such a way as to consider time outs and such of other dependent tasks. I haven't looked into it, I had other stuff to do besides I will not be able to use unsupported (by Red Hat in my case) features on a cluster - the inclusion in the kernel would make it a likely addition to the enterprise distributions the next round.

Maybe, this business (like You say) is best left to some other management application, maybe a Pacemaker resource like systemd could start a unit or something. keepalived would probably need some kind of notify script that is executed on migration. I am just thinking out loud here.

WireGuarding the mainline

Cyberax — Tue, 07 Aug 2018 06:17:41 +0000

To be fair, the bulk of Zinc code consists mostly of cut&pasted crypto implementations, including manually unrolled assembly code.

WireGuarding the mainline

zx2c4 — Tue, 07 Aug 2018 05:54:20 +0000

Donenfeld seemed to be trying to make things harder yet: his "Zinc" cryptography API was posted as a single, 24,000-line patch that was duly rejected by the mailing-list filters. It is available in his repository, though, for those who want to take a look. The changelog describes the motivations for Zinc in the sort of, shall we say, highly self-assured language favored by security-oriented developers. It seems designed to raise enough hackles to prevent serious consideration of what is actually being proposed.

Certainly not "trying to make things harder" and it wasn't "designed to raise enough hackles". But rest assured the Zinc portion will be considerably different in form for v2. Split into several separably reviewable parts, each message will have very specific commentary on the particulars of each patch, so there will be less of the language that's "favored by security-oriented developers," opting instead to get right down to the point of the patch. And regardless, I'm happy iterating on this until it's acceptable, as I think it's a significant improvement on the status quo.

WireGuarding the mainline

josh — Tue, 07 Aug 2018 05:35:15 +0000

> what in an average Linux desktop distro actually makes use of the current crypto API?

Encrypted disks, filesystems that support file encryption, the CIFS/SMB filesystem, signed kernel modules, TCP Fast Open, Bluetooth, and various things that use compression (which goes through the crypto subsystem as well).

WireGuarding the mainline

unixbhaskar — Tue, 07 Aug 2018 03:23:46 +0000

Whoa! that sounds great. Why people jumping for more feature??? It is designed to be used with one single thing and it should do what it suppose to do. More feature(most of them not used by anybody) , go and take a look at the other part. If it's sticking with its current form with little bit enhancement in the future, which was suggested by other people, it will be good.

WireGuarding the mainline

flussence — Tue, 07 Aug 2018 01:54:58 +0000

I suppose this is as good a place to ask as any: what in an average Linux desktop distro actually makes use of the current crypto API? I see a few things required for filesystem checksums and wireless networking, but the latter is a weird case because hostapd/wpa_supplicant also wants userspace SSL libraries to speak WPA.

(Also I think this is the most positive reaction I've seen from Linus to anything. Maybe that comes from using other VPNs? :-)