Kernel tree / config published someplace?

#1

I noticed modules support is enabled in your kernel, and was hoping to activate at least Wireguard and GRE for some experimentation. I thought I could achieve this by rebuilding the kernel modules myself and shipping them in the image, but this raises the question of where the kernel binary and config comes from. I could not find it in GitHub. Is it currently private, or perhaps some off-the-shelf kernel from someplace? There is a /proc/config.gz which could be used to rebuild it, if the kernel was an unpatched vanilla tree.

I’d like this for two wildly experimental reasons:

  • Running an IPv4 Wireguard connection from within the containers to an existing Kubernetes cluster which cannot be made to speak IPv6 easily (or at all). This would be to allow the containers to reach k8s services without the expense of SSL handshakes over the public Internet or exposing those services publicly at all

  • Running a GRE tunnel over the Wireguard link, to allow the containers to join multicast groups published on the remote end (Wireguard basically doesn’t support multicast yet). In the experimental app, this boils away a lot of complexity with selectively routing live streams to the appropriate containers, and avoids duplicating a bunch of existing infrastructure already present on the remote end.

This is mostly for fun, I guess there is room for breakage if your kernels are silently upgraded, but it also seems like a fairly awesome use case that is only possible due to your hosting model

#2

Hey! Cool question.

Our guest kernels are standard Linux with the recommended Firecracker kernel config.

There’s nothing proprietary at all in our guest kernel and I suppose we could in theory publish it, although I don’t think we’ll be making that kernel part of our official ABI. Our bigger concern would be that we might want to change it from time to time.

I’ve done v4 WireGuard from a guest VM using wireguard-go, which worked fine, so I think your kernel WireGuard plan would work too. Our guest kernel should already have WireGuard support!

For GRE, you probably will need to load a module, which will be tricky without the tooling for this kernel version.

#3

Awesome, thanks for the quick reply, I’ll give wireguard-go a shot. Didn’t even think to check for tun.

#4

I think native WireGuard should work? We have WireGuard support in the current guest kernel.

#5

Seems I’m blind :slight_smile: Ok so the first part of this is solved out of the box, modulo some way to distribute tunnel keys. That’s probably enough to chew on for the rest of the week.

I’ll drop a note on the thread when coming back for GRE (assuming a better option for multicast doesn’t turn up)

Thanks again!

#6

Please do. I’m interested in what it’s going to take for people to load kernel modules, and if it turns out there’s a use case for it, we’ll put GRE in the standard guest kernel.