There are two options:

1. You can move the Wireguard interface into the container. This takes some work to set up and prevents the host from using the interface.
2. If the host needs connectivity over the same Wireguard tunnel, the host can create virtual interfaces and perform network address translation (NAT) to forward traffic to and from the child.

I have most confidence in the first option, especially as the surrounding configuration evolves. You’re less likely to subtly break the configuration and start leaking traffic in the future.

Both options are shown here. NixOS is my preferred system, so I’ve specified the configuration using NixOS here. Translation to a non-NixOS system should be straightforward.

Option 1: move the Wireguard interface into the container

Here we set up Wireguard in a new network namespace and move that namespace into the container. The Wireguard interface must be created in the main (host) network namespace and subsequently moved into the new namespace: this allows Wireguard to communicate with the endpoint over the main network interface.

The following sets up the Wireguard interface in the container as the default route, and allows some traffic between the LAN and the container through a virtual ethernet interface. This configuration assumes the host’s main network interface is called enp3s0.

systemd-networkd does not yet provide the required tools to do this. Instead, this configuration defines systemd units to perform the network setup.

{ lib, pkgs, ... }:
let
  wgIpv4 = "1.2.3.4";
  wgIpv6 = "1:2:3:4::0";

  natIpv4Host = "192.168.10.10";
  natIpv4Ns = "192.168.10.11";
in
{
  networking.useDHCP = false;
  networking.interfaces."enp3s0" = {
    useDHCP = true;
  };

  environment.etc."netns-wgns-wg-ips".text = ''
    IPV4=${wgIpv4}
    IPV6=${wgIpv6}
  '';
  environment.etc."netns-wgns-veth-ips".text = ''
    IPV4_HOST=${natIpv4Host}
    IPV4_NS=${natIpv4Ns}
  '';

  systemd.services = {
    "netns@" = {
      description = "%i network namespace";
      serviceConfig = with pkgs; {
        Type = "oneshot";
        RemainAfterExit = true;
        ExecStart = "${iproute}/bin/ip netns add %i";
        ExecStop = "${iproute}/bin/ip netns del %i";
      };
    };

    "lo@" = {
      description = "loopback in %i network namespace";

      bindsTo = [ "netns@.service" ];
      after = [ "netns@.service" ];

      serviceConfig = {
        Type = "oneshot";
        RemainAfterExit = true;
        ExecStart =
          let
            start = with pkgs; writeShellScript "lo-up" ''
              set -e

              ${iproute}/bin/ip -n $1 addr add 127.0.0.1/8 dev lo
              ${iproute}/bin/ip -n $1 link set lo up
            '';
          in
          "${start} %i";
        ExecStopPost = with pkgs; "${iproute}/bin/ip -n %i link del lo";
      };
    };

    # This unit assumes a file named /etc/netns-<network namespace>-veth-ips
    # exists to set IPV4_HOST and IPV4_NS environment variables to valid
    # IPv4 addresses to be used for the two sides of the veth interface.
    "veth@" = {
      description = "virtual ethernet network interface between the main and %i network namespaces";

      bindsTo = [ "netns@.service" ];
      after = [ "netns@.service" ];

      serviceConfig = {
        Type = "oneshot";
        RemainAfterExit = true;
        ExecStart =
          let
            start = with pkgs; writeShellScript "veth-up" ''
              set -e

              . /etc/netns-$1-veth-ips

              # As this templated unit potentially has multiple units running
              # simultaneously, the interface is created with a unique name in
              # the main network namespace, then moved to the new network
              # namespace and renamed.
              ${iproute}/bin/ip link add ve-$1 type veth peer name eth-lan-$1
              ${iproute}/bin/ip link set eth-lan-$1 netns $1
              ${iproute}/bin/ip -n $1 link set dev eth-lan-$1 name eth-lan
              ${iproute}/bin/ip addr add $IPV4_HOST/32 dev ve-$1
              ${iproute}/bin/ip -n $1 addr add $IPV4_NS/32 dev eth-lan
              ${iproute}/bin/ip link set ve-$1 up
              ${iproute}/bin/ip -n $1 link set eth-lan up
              ${iproute}/bin/ip route add $IPV4_NS/32 dev ve-$1
              ${iproute}/bin/ip -n $1 route add $IPV4_HOST/32 dev eth-lan
            '';
          in
          "${start} %i";
        ExecStopPost =
          let
            stop = with pkgs; writeShellScript "veth-down" ''
              ${iproute}/bin/ip -n $1 link del eth-lan
              ${iproute}/bin/ip link del ve-$1
            '';
          in
          "${stop} %i";
      };
    };

    # This unit assumes a Wireguard configuration file exists at
    # /etc/wg-<network namespace>.conf. Note this is a Wireguard configuration
    # file, not a wg-quick configuration file. See "CONFIGURATION FILE FORMAT
    # EXAMPLE" in wg(8).
    #
    # This further assumes a file exists at /etc/netns-<network
    # namespace>-wg-ips to set IPV4 and IPV6 environment variables to valid IP
    # addresses to be used by the Wireguard interface.
    "wg@" = {
      description = "wg network interface in %i network namespace";

      bindsTo = [ "netns@.service" ];
      wants = [
        "network-online.target"
        "nss-lookup.target"
      ];
      after = [
        "netns@.service"
        "network-online.target"
        "nss-lookup.target"
      ];

      serviceConfig = {
        Type = "oneshot";
        RemainAfterExit = true;
        Restart = "on-failure";
        RestartSec = 3;
        ExecStart =
          let
            start = with pkgs; writeShellScript "wg-up" ''
              set -e

              . /etc/netns-$1-wg-ips

              # As this templated unit potentially has multiple units running
              # simultaneously, the interface is created with a unique name in
              # the main network namespace, then moved to the new network
              # namespace and renamed.
              ${iproute}/bin/ip link add wg-$1 type wireguard
              ${iproute}/bin/ip link set wg-$1 netns $1
              ${iproute}/bin/ip -n $1 link set dev wg-$1 name wg0
              ${iproute}/bin/ip -n $1 addr add $IPV4 dev wg0
              ${iproute}/bin/ip -n $1 -6 addr add $IPV6 dev wg0
              ${iproute}/bin/ip netns exec $1 \
                ${wireguard-tools}/bin/wg setconf wg0 /etc/wg-$1.conf
              ${iproute}/bin/ip -n $1 link set wg0 up
              ${iproute}/bin/ip -n $1 route add default dev wg0
              ${iproute}/bin/ip -n $1 -6 route add default dev wg0
            '';
          in
          "${start} %i";
        ExecStopPost =
          let
            stop = with pkgs; writeShellScript "wg-down" ''
              ${iproute}/bin/ip -n $1 route del default dev wg0
              ${iproute}/bin/ip -n $1 -6 route del default dev wg0
              ${iproute}/bin/ip -n $1 link del wg0
            '';
          in
          "${stop} %i";
      };
    };
  };

  boot.kernel.sysctl = {
    "net.ipv4.ip_forward" = 1;
  };
  networking.nftables = {
    enable = true;
    ruleset = ''
      table inet nat {
        chain postrouting {
          type nat hook postrouting priority 100; policy accept;

          iifname "enp3s0" oifname "ve-wgns" masquerade
        }
        chain prerouting {
          type nat hook prerouting priority -100; policy accept;

          iifname "enp3s0" tcp dport { ssh, http } dnat ip to ${natIpv4Ns}
        }
      }
    '';
  };

  systemd.services."container@wgcontainer" = {
    requires = [
      "lo@wgns.service"
      "veth@wgns.service"
      "wg@wgns.service"
    ];
    after = [
      "lo@wgns.service"
      "veth@wgns.service"
      "wg@wgns.service"
    ];
  };
  containers = {
    wgcontainer = {
      specialArgs = { inherit inputs; };
      autoStart = true;

      extraFlags = [ "--network-namespace-path=/run/netns/wgns" ];

      config = { ... }: {
        networking.useHostResolvConf = lib.mkForce false;
        networking.nameservers = [
          # Alternatively, use a DNS server provided by the VPN
          "1.1.1.1"
          "9.9.9.9"
        ];
        networking.useDHCP = false;
        networking.useNetworkd = true;

        networking.firewall.enable = false;
        networking.nftables = {
          enable = true;
          ruleset = ''
            table inet filter {
              chain output {
                # Drop everything by default
                type filter hook output priority 100; policy drop;

                oif lo accept comment "Accept all packets sent to loopback"
                oifname "wg0" accept comment "Accept all packets that go out over Wireguard"

                ct state established,related accept comment "Accept all packets of established traffic"
              }

              chain input {
                # Drop everything by default
                type filter hook input priority filter; policy drop;

                iif lo accept
                iif != lo ip daddr 127.0.0.1/8 counter drop comment "drop connections to loopback not coming from loopback"

                iifname "eth-lan" accept comment "Accept all packets coming from lan"
                iifname "wg0" tcp dport { 1111, 2222 } accept comment "Accept specific ports coming from Wireguard"

                ct state established,related accept
              }
            }
          '';
        };
      };
    };
  };
}

This configuration defines systemd units to bring up and take down the network parts required for the container’s network. In this configuration the units are templated (i.e., their name ends with the @-suffix) to allow multiple Wireguard network namespaces to be created simultaneously. If you’d start units wg@wgns1.service and wg@wgns2.service, two network namespaces would be created (wgns1 and wgns2), each with their own Wireguard interfaces. This aspect of the configuration might not be necessary for your use-case.

The important details here are:

1. The container is started using --network-namespace-path=/run/netns/<namespace name> to bind the network namespace to the container. This makes the namespace unavailable to the host and sets the namespace up as the main namespace in the container.
2. The wg@.service unit sets up the Wireguard interface in the main network namespace and moves it to the namespace to be used by the container. The interface is set up as the default route.
3. The veth@.service unit sets up a virtual ethernet interface pair between the host’s main network namespace and the namespace to be used by the container. This allows communication between the host and the container. IPv4 forwarding is enabled using sysctl and nftables rules are set up to destination-NAT some incoming traffic from the host to the container.
4. The lo@.service unit creates a loopback device in the network namespace. This is required to allow processes on the container to communicate locally with other processes on the container using the network stack.
5. The veth@.service and wg@.service units read some configuration from disk based on the network namespace name. The units are only passed the network namespace name as systemd template argument, but need more configuration information (such as IP addresses and Wireguard configuration files). If you don’t use templated units, the values can be hardcoded instead.
6. For hardening, the container’s firewall allows outbound traffic to go out of only the Wireguard interface, except for traffic that is related to earlier accepted traffic. Incoming LAN traffic is accepted (but only traffic forwarded by the host can reach the container). The container cannot initiate LAN connections. It also does not have routes set up to reach other systems on the host’s network.

Option 2: NAT to and from the container

This assumes the host’s main network interface is called enp3s0 and a Wireguard interface is already set up named wg0. This further assumes the wg0 interface is set as the default route. This configuration ensures container traffic to the internet only goes out through the Wireguard interface; the traffic is dropped otherwise. See here how you might set up Wireguard on the host.

{ ... }:
{
  boot.kernel.sysctl = {
    "net.ipv4.ip_forward" = 1;
    "net.ipv6.ip_forward" = 1;
  };
  networking.nftables = {
    enable = true;
    ruleset = ''
      table inet wg-wg0 {
        chain forward {
          type filter hook forward priority filter; policy drop;

          # Dynamically rewrite the TCP max segment size to the MTU discovered on this path
          tcp flags syn tcp option maxseg size set rt mtu

          iifname "ve-wgcontainer" oifname "wg0" accept
          ct state established,related accept comment "Accept all packets of established traffic"
          ct status dnat accept
        }
        chain postrouting {
          type nat hook postrouting priority 100; policy accept;

          iifname "ve-wgcontainer" oifname "wg0" masquerade
          iifname "enp3s0" oifname "eth-lan" masquerade
        }
        chain prerouting {
          type nat hook prerouting priority -100; policy accept;

          iifname "wg0" meta nfproto ipv4 tcp dport { 1111, 2222 } dnat to 192.168.100.11
          iifname "wg0" meta nfproto ipv6 tcp dport { 1111, 2222 } dnat to fc00:100::2

          iifname "enp3s0" meta nfproto ipv4 tcp dport { http } dnat to 192.168.105.11
        }
      }
    '';
  };

  containers = {
    wgcontainer = {
      autoStart = true;

      privateNetwork = true;

      hostAddress = "192.168.100.10";
      localAddress = "192.168.100.11";
      hostAddress6 = "fc00:100::1";
      localAddress6 = "fc00:100::2";

      extraVeths."eth-lan" = {
        hostAddress = "192.168.105.10";
        localAddress = "192.168.105.11";
      };

      config = { ... }:
      {
        networking.firewall.enable = false;
        networking.nftables = {
          enable = true;
          tables."nixos-fw".enable = false;
          ruleset = ''
            table inet filter {
              chain output {
                # Drop everything by default
                type filter hook output priority 100; policy drop;

                oif lo accept comment "Accept all packets sent to loopback"
                oifname "eth0" accept comment "Accept all packets that go out over Wireguard"

                ct state established,related accept comment "Accept all packets of established traffic"
              }

              chain input {
                # Drop everything by default
                type filter hook input priority filter; policy drop;

                iif lo accept
                iif != lo ip daddr 127.0.0.1/8 counter drop comment "drop connections to loopback not coming from loopback"

                iifname "eth-lan" accept comment "Accept all packets coming from lan"
                iifname "eth0" tcp dport { 1111, 2222 } accept comment "Accept specific ports coming from Wireguard"

                ct state established,related accept
              }
            }
          '';
        };
      };
    };
  };
}

An interface pair (named eth0 on the container and ve-wgcontainer on the host) is set up by the containers.wgcontainer.{host,local}Address rules. It is automatically set up as the default route in the container and is used exclusively to send traffic through the Wireguard tunnel (i.e., to reach the internet and potentially to reach a network on the other side of the tunnel). The configuration further sets up eth-lan (identically named on the container and host) to forward some LAN traffic to the container. In this configuration the container cannot initiate connections to the LAN; it can only respond to them.

The important details on the host are:

1. Allow IP forwarding using sysctl. This is required to perform destination-NAT to the container.
2. For security, don’t forward any traffic by default.
3. Accept forwarding all traffic coming from the container going out through Wireguard.
4. Accept forwarding established/related traffic: this allows forwarding all traffic necessary for flows that were initiated and accepted earlier.
5. Accept forwarding destination-NAT’ed traffic. All traffic that is explicitly “port-forwarded” by destination-NAT rules is accepted.
6. Masquerade traffic from the container interface ve-wgcontainer to the Wireguard interface wg0—this rewrites the source IP address from 192.168.100.11 or fc00:100::2 to the IP on the wg0 interface, so the other side of the tunnel knows where to send responses (it is unaware of this local network setup). The remote peer will most likely perform its own NAT on this traffic if it is to reach the internet.
7. Masquerade traffic from the LAN interface enp3s0 to the eth-lan interface. This pretends all LAN traffic comes from the host, effectively hiding the LAN from the container. The container has a route set up to the other side of the eth-lan interface, but only for the host’s IP 192.168.105.10.
8. As an example, forward some traffic from the Wireguard interface addressing ports 1111 and 2222 to the container, and the HTTP port (80) is forwarded from the LAN to the container. This enables some specific traffic that is not initiated by the container itself.

The container configuration is simpler. Some hardening is applied:

1. All outgoing traffic is dropped by default. Traffic going to the loopback interface is allowed, traffic that goes out to the interface that the host NATs to Wireguard is allowed, and traffic that is established/related to existing flows is allowed. This means the container cannot initiate any network connection except for those that go out through Wireguard.
2. All incoming traffic from the LAN interface is allowed, and some traffic to ports from the Wireguard interface is allowed. Again, established/related traffic is allowed.

NixOS is my preferred system, so I’ve specified the configuration using NixOS here. Translation to a non-NixOS system should be straightforward.

{ ... }:
let
  # This peer's IPv4 and IPv6 addresses
  wgIpv4 = "1.2.3.4";
  wgIpv6 = "1:2:3:4::";

  # Variables controlling connection marks and routing tables IDs. You probably
  # don't need to touch this.
  wgFwMark = 4242;
  wgTable = 4000;
in
{
  # DNS is required if the Wireguard endpoint is a hostname.
  networking.nameservers = [
    "1.1.1.1"
    "9.9.9.9"
  ];
  services.resolved.enable = true;

  networking.useNetworkd = true;
  systemd.network = {
    enable = true;
    netdevs."15-wg0" = {
      netdevConfig = {
        Kind = "wireguard";
        Name = "wg0";
        MTUBytes = "1420";
      };
      wireguardConfig = {
        PrivateKeyFile = "/path/to/this-peer's-wg-key";
        FirewallMark = wgFwMark;
        RouteTable = "off";
      };
      wireguardPeers = [
        {
          wireguardPeerConfig = {
            PublicKey = "<The remote peer's public key here>";
            # Depending on the connection, add a pre-shared key file
            # PresharedKeyFile = "/path/to/preshared-key";
            Endpoint = "wg.example.com:51820";
            AllowedIPs = [ "0.0.0.0/0" "::/0" ];
            PersistentKeepalive = 25;
            RouteTable = "off";
          };
        }
      ];
    };
    networks."15-wg0" = {
      matchConfig.Name = "wg0";
      # Set to this peer's assigned Wireguard address
      address = [
        "${wgIpv4}/32"
        "${wgIpv6}/128"
      ];
      networkConfig = {
        # If DNS requests should go to a specific nameserver when the tunnel is
        # established, uncomment this line and set it to the address of that
        # nameserver. But see the note at the bottom of this page.
        # DNS = "1.1.1.1";
      };
      routingPolicyRules = [
        {
          routingPolicyRuleConfig = {
            Family = "both";
            Table = "main";
            SuppressPrefixLength = 0;
            Priority = 10;
          };
        }
        {
          routingPolicyRuleConfig = {
            Family = "both";
            InvertRule = true;
            FirewallMark = wgFwMark;
            Table = wgTable;
            Priority = 11;
          };
        }
      ];
      routes = [
        {
          routeConfig = {
            Destination = "0.0.0.0/0";
            Table = wgTable;
            Scope = "link";
          };
        }
        {
          routeConfig = {
            Destination = "::/0";
            Table = wgTable;
            Scope = "link";
          };
        }
      ];
      linkConfig.RequiredForOnline = false;
    };
  };

  networking.nftables = {
    enable = true;
    ruleset = ''
      table inet wg-wg0 {
        chain preraw {
          type filter hook prerouting priority raw; policy accept;
          iifname != "wg0" ip daddr ${wgIpv4} fib saddr type != local drop
          iifname != "wg0" ip6 daddr ${wgIpv6} fib saddr type != local drop
        }
        chain premangle {
          type filter hook prerouting priority mangle; policy accept;
          meta l4proto udp meta mark set ct mark
        }
        chain postmangle {
          type filter hook postrouting priority mangle; policy accept;
          meta l4proto udp meta mark ${toString wgFwMark} ct mark set meta mark
        }
      }
    '';
  };
}

This configuration is similar to one that the wg-quick utility sets up. There are a number of important things going on.

1. FirewallMark on the Wireguard config inside the netdev block sets a mark on packet metainformation outgoing from the Wireguard tunnel. This mark is used in the routing policy rules: the configuration creates a routing table, with an associated high-priority routing policy rule, to send all packets without this mark to the Wireguard interface.

   Packets outgoing from the Wireguard interface must be routed to the main interface to make it to the Wireguard peer: if it were routed to the Wireguard interface, it would loop forever. Instead, an outgoing Wireguard packet traverses the routing chain again, and, this time with the mark set in the metainformation, does not match the routing rule, skips the Wireguard routing table, and goes out the main, non-tunnel interface.

2. The firewall contains three chains.

   1. The preraw chain is a security measure and drops traffic directed towards the tunnel’s IP not coming from either the tunnel or the local machine.
   2. The postmangle chain checks if the firewall mark Wireguard creates is set, and if so, sets it on the conntrack flow.
   3. The premangle chain checks if the packet is part of a conntrack flow that has a mark set. If so, it sets that mark on the packet. Incoming traffic related to earlier traffic that was marked will now also get marked.

   The last two rules are necessary if strict reverse path forwarding is set and the firewall mark is included in reverse path route lookup. This corresponds to:

   $ sysctl net.ipv4.conf.<interface>.rp_filter
   net.ipv4.conf.<interface>.rp_filter = 1
   
   $ sysctl net.ipv4.conf.<interface>.src_valid_mark
   net.ipv4.conf.<interface>.src_valid_mark = 1
   

   If rp_filter is 0 (turned off) or 2 (loose), or if src_valid_mark = 0, these firewall rules do not need to be set.

3. The MTU is set to 1420. This is the maximum possible MTU when the Wireguard connection tunnels over IPv6 on an interface with an MTU of 1500.

   In case of issues, the MTU can be safely lowered to, for example, 1320. When tunneling over IPv4—which almost always has a 20 bytes header instead of IPv6’s 40 bytes—the MTU can be increased to 1440.

4. The high-priority routing policy rule checking paths on the main table with SuppressPrefixLength = 0 is for convenience. It tests the destination IP against paths in the main table that have a prefix length other than 0—i.e., any non-default route that matches is taken. This allows outbound traffic to still reach the LAN.

Notes:

• When uncommenting the DNS server, DNS requests can still go out over the other interfaces. To prevent that, add

  or

  Be aware that in the current version of systemd-networkd (255.2) this causes a problem if the endpoint is specified as a hostname: the hostname resolve request for that hostname will go out over the offline Wireguard interface and will not receive a response.

  If you want to make sure all traffic headed to the internet always goes through the Wireguard tunnel, see here for possible configurations. Routing rules are not very reliable for that use-case.

• You can forego explicit configuration of the Wireguard routes when you remove RouteTable="off". You probably still want to add the convenience routing policy rule matching against non-zero prefix routes in the main table. I prefer this more explicit approach.

If/when networkd supports specifying network namespaces, a different solution is possible without routing hacks. See the “The New Namespace Solution” in this article on Wireguard website. There is a request on the systemd GitHub repository for the required functionality.

import XMonad
import qualified XMonad.StackSet as S

-- Get the name of the active layout.
getActiveLayoutDescription :: X String
getActiveLayoutDescription = do
    workspaces <- gets windowset
    return $ description . S.layout . S.workspace . S.current $ workspaces

We can use this function in keybindings as follows. Here I’m using the BinarySpacePartition layout, and my other layouts are based on Tall. Depending on whether I have BSP active or not, I send different messages.

-- ...

import XMonad.Layout.BinarySpacePartition

myKeys = [ ((mod4Mask .|. shiftMask, xK_l), do
            layout <- getActiveLayoutDescription
            case layout of
                "BSP" -> sendMessage $ ExpandTowards R
                _     -> sendMessage Expand
           )
         , ((mod4Mask .|. shiftMask, xK_h), do
            layout <- getActiveLayoutDescription
            case layout of
                "BSP" -> sendMessage $ ExpandTowards L
                _     -> sendMessage Shrink
           )
         ]

Note that you can give your layouts custom names through Renamed.

Using setcap, we might add a capability to a file as follows:

$ sudo setcap cap_net_raw+epi /path/to/wine 

However, for security reasons, when a file has capabilities set, all insecure environment variables are removed upon executing it. This includes variables such as LD_LIBRARY_PATH. Binaries depending on this variable to find dynamic libraries will fail to execute. This is often the case with OpenGL drivers. I encountered this when attempting to play a game through Wine that used ICMP—having set cap_net_raw+epi on the wine binary (or wine-preloader), OpenGL could no longer be found, resulting in:

0009:err:wgl:X11DRV_WineGL_InitOpenglInfo  couldn't initialize OpenGL, expect
problems failed to initialise opengl

This can be fixed ad-hoc by patching the binary with patchelf and adding the OpenGL library location, for example:

$ patchelf --print-rpath /path/to/wine
/some/lib:/some/other/lib

$ echo $LD_LIBRARY_PATH
/run/opengl-driver/lib:/run/opengl-driver-32/lib

$ patchelf --set-rpath "/run/opengl-driver/lib:/run/opengl-driver-32/lib:/some/lib:/some/other/lib" /path/to/wine

However, it is a pain to do this for all binaries you might want to give capabilities. The Linux kernel allows ambient capabilities where all child processes inherit the capabilities implicitly, removing the need to set them on binaries. Using capsh we can get a shell with ambient capabilities set:

$ sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1 --user=thomas --addamb=cap_net_raw --
bash: /root/.bashrc: Permission denied

$ capsh --print
capsh --print
Current: = cap_net_raw+eip
Bounding set =...
Ambient set =cap_net_raw
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=1000(thomas)
gid=100(users)
groups=1(wheel),57(networkmanager),100(users)

$ whoami
thomas

$ echo $USER
root

We now have cap_net_raw+eip in our capabilities, and it is also in our ambient set. Something unfortunate occurs here with environment variables, though. We are user thomas, but we have inherited the environment variables of root. This is easily solved. We can export our current environment variables before performing capsh, and then source them back once in the privileged shell:

$ export -p > ./savedenv
$ sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1 --user=thomas --addamb=cap_net_raw -- -c "source ./savedenv; rm ./savedenv; /usr/bin/env bash"

$ whoami
thomas

$ echo $USER
thomas

This works, but admittedly the way the environment variables are restored is quite hacky. In any case, you can now launch processes from this shell, and they’ll inherit your capabilities.

$ wine ping example.com
Pinging example.com [93.184.216.34] with 32 bytes of data:
Reply from 93.184.216.34: bytes=32 time=87ms TTL=57
Reply from 93.184.216.34: bytes=32 time=90ms TTL=57
Reply from 93.184.216.34: bytes=32 time=87ms TTL=57
Reply from 93.184.216.34: bytes=32 time=89ms TTL=57

Ping statistics for 93.184.216.34
	Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
	Minimum = 87ms, Maximum = 90ms, Average = 88ms

The straightforward approach is to let Nix handle all R package management. However, sometimes it is useful to manage packages through the various R tools such as the built-in install.packages or install utilities provided by the devtools package.

R looks for installed packages in the R library directories, of which there are two types: the system library and the user library. By default these package management tools install packages in the first-specified user library directory. The user library directories can be specified through the R_LIBS_USER environment variable. We can use Nix to specify a unique library directory per project.

For example, create a nix.shell in your project root as follows:

with import <nixpkgs> {};
let
  my-r = rWrapper.override {
    packages = with rPackages; [
      ggplot2
      plyr
      tidyr
      devtools
    ];
  };
in
  pkgs.mkShell {
    buildInputs = [
      bashInteractive
      my-r
    ];
    shellHook = ''
      mkdir -p "$(pwd)/_libs"
      export R_LIBS_USER="$(pwd)/_libs"
    '';
  }

Activate it in your shell by running $ nix-shell.

This makes available R with ggplot, plyr, tidyr and devtools. It creates a subdirectory in your project root, _libs, where the project’s R user library is located.

Of course, Python’s VirtualEnv also enables us to do this. Nix, however, is more powerful. It can handle all our system’s packages; not just Python’s. This means it enables us to hold different versions of any dependency. For example, if one project requires a specific version of OpenCL and another project requires an incompatible version, VirtualEnv won’t help us. Nix will.

There are many Python packages, and to install one such package through Nix requires it to be available in the Nix package repository. Understandably, not all Python packages are packaged for Nix—and those that are, often are not the newest version, nor at some other specific version we require.

We can use Nix to provision a Python environment for our project that works similarly to VirtualEnv’s. We can then use pip to handle such per-project Python dependencies, allowing us to grab Python packages directly from the regular Python package repositories without going through Nix. This also allows us to quickly get to work with others’ Python projects that are not set up to work with Nix.

We do this by managing Python and pip as Nix dependencies (as well as any any other Python packages we wish to have managed through Nix, for example those with system dependencies such as NumPy).

For example, create a nix.shell in your project root as follows:

with import <nixpkgs> {};
let
  my-python-packages = python-packages: [
    python-packages.pip
    python-packages.numpy
  ];
  my-python = python36.withPackages my-python-packages;
in
  pkgs.mkShell {
    buildInputs = [
      bashInteractive
      my-python
    ];
    shellHook = ''
      export PIP_PREFIX="$(pwd)/_build/pip_packages"
      export PYTHONPATH="$(pwd)/_build/pip_packages/lib/python3.6/site-packages:$PYTHONPATH" 
      unset SOURCE_DATE_EPOCH
    '';
  }

Activate it in your shell by running $ nix-shell.

This makes available Python 3.6, pip and NumPy. Environment variable PIP_PREFIX tells pip to install its packages in subdirectory _build in your project root’s folder. PYTHONPATH is extended with the directory where this project’s pip will now install packages. These environment changes are necessary because this Python installation lives inside the read-only Nix store, and pip would not be able to install packages there.

Note that we unset SOURCE_DATE_EPOCH. Nix sets it to a value of 1 for reproducible builds, causing Python’s bdist_wheel to fail as it requires SOURCE_DATE_EPOCH to correspond to 1980 or later.

You can now use pip as you normally would, such as

$ pip install -r requirements.txt

On Windows, LLDB only works reliably with 32-bit binaries. As such, this guide will outline how to get debugging working for 32-bit targets.

To get this working:

1. Install LLDB. You can get it by installing the LLVM tools, but the current official LLVM installer for Windows does not include LLDB. You can get an installer including 32-bit LLDB here. You do not have to add LLDB to your system environment path.

2. LLDB requires python35.dll, which which can be downloaded here. As we are using a 32-bit version of LLDB, make sure to install the 32-bit version of Python 3.5 as well.You also do not have to add this version of Python to your system environment path.

3. If you do not have it already, install a 32-bit toolchain for Rust. You do not have to make it the default toolchain. In command prompt, execute:

   rustup install stable-i686-pc-windows-gnu
   

   To list your currently installed toolchains, excute:

   rustup show
   

4. Install the CodeLLDB extension for Visual Studio Code. Restart Visual Studio Code. This enables support for LLDB.

5. If you did not add LLDB or Python 3.5 to your environment path, configure Visual Studio Code so the extension knows where to find them.You should set the LLDB executable to lldb.exe inside the bin folder where you installed LLVM.Set the Path executable environment variable to the folder where you installed 32-bits Python 3.5, followed by ;{$env:Path}. This tells LLDB where to find Python.

   {
       "lldb.executable": "C:\\Path\\To\llvm-6.0.0-r313613\\bin\\lldb.exe",
       "lldb.executable_env": {
           "Path": "C:\\Path\\To\\Python35;${env:Path}"
       }
   }
   

   

6. Add a debug launch configuration for your project. To open the Debug panel, hit Ctrl+Shift+D. Click on the dropdown, and choose “Add configuration…” Choose the LLDB Cargo Launch configuration. The settings depend on our project structure, but the following probably works:

   {
       "type": "lldb",
       "request": "launch",
       "name": "Debug Cargo LLDB",
       "sourceLanguages": ["rust"],
       "cargo": {
           "args": [
               "+stable-i686-pc-windows-gnu",
               "build"
           ]
       },
       "program": "${cargo:program}",
       "args": []
   }
   

   

   The argument +stable-i686-pc-windows-gnu tells cargo to use this specific 32-bit toolchain to compile your code with, regardless of your current default toolchain. This means you can debug with the 32-bit toolchain without setting it as your default.

   If you need to target a specific binary, add "--bin=binary_name" at the end of the cargo.args list.

7. If you want to, you can additionally add "debug.inlineValues": true to your user or workspace settings to show values inside the editor.

8. Place some breakpoints, then press Debug or hit F5!

In the rocket simulation post, we arrived at the following formula:

with v the rocket velocity, t the time, v_e the fuel exhaust velocity, M the rocket mass, G the gravitational constant, M_\oplus the mass of Earth, and r the distance of the rocket to the center of Earth. Rewriting, we find the instantaneous change in velocity:

As in our original derivation of the rocket equation, we take the definite integral of all change terms from the initial to the final situations: dv is taken from the initial to the final velocity, dM from the initial to the final mass, and dt from the initial to the final time:

here t_\text{burn} = t_f - t_i is the total burn time. To find the fuel requirement, we want the formula for M_i as a function of \Delta v. Symbolic equation solvers happily rewrite the formula for us:

with \text{W}{\left(\cdot\right)} the Lambert W function, and b = -dM/dt such that t_\text{burn} = \left( M_i - M_f \right) / b.

We use the same values as before: the dry mass of the rocket is M_f = 2\,000 \text{ kg}, required escape velocity \Delta v = 1.118 \cdot 10^4 \text{ m/s}, and fuel exhaust v_e = 5\,000 \text{ m/s}. Plugging this into the equation, We find that the initial mass is 37\,667 \text{ kg}, and so the fuel required is 35\,667 \text{ kg}.

This number is considerably higher than the 24\,500 \text{ kg} found through simulation. And this makes sense: at the end of the simulated burn, the rocket has achieved a height of 600 \text{ km} over sea level. This is 10% of the radius of the Earth. Deceleration due to gravity at that point is 8.2 \text{ m}/\text{s}^2, rather than 9.8 \text{ m}/\text{s}^2 at sea level. Furthermore, the necessary escape velocity will have decreased to 10.69 \text{ km/s} from 11.18 \text{ km/s} at sea level. As such, this closed-form approximation is overestimating the fuel requirements by taking those values as constant from sea level at Earth.

This approximation gets more accurate as the rocket’s acceleration increases (e.g. through higher burn rates), resulting in lower burn times, thereby making the assumption of constant gravity and escape velocity more valid. Once the burn rate is taken as instantaneous, this approximation yields the same result as the naive rocket equation.

You can try out the equation interactively here. Note that not all parameter combinations make escape velocity achievable.

The language is formally defined with a context-free grammar and typing rules. In this post an implementation of an &SPL source code compiler implemented in Haskell will be discussed. The compiler compiles the source code into assembly for a Simple Stack Machine [SSM] (http://www.staff.science.uu.nl/~dijks106/SSM/) in a four-part process of lexing, parsing, typing and code generation. The source code is available on GitHub.

Grammar

The &SPL grammar defines the legal syntax of the language. The semantics are only partially defined through the grammar, and are more fully defined through the language typing rules defined in the Typing section.

The context-free grammar is as follows:

Here alpha and alphaNum refer to alphabetical and alphabetical or numerical characters respectively.

Operator precedence, associativity and semantics

The operator precedence, associativity and semantics of the binary operators are as follows:

The unary operators are defined as follows:

Lexing

The lexing process is the initial phase of &SPL compilation. Through lexing raw source code is turned into a list of tokens. Some such tokens represent single characters in the source code, but other tokens represent more complex structures. For example, the source code string 49020 is represented as a single token TConstant (CInt 49020).

The lexer is implemented as a set of recognizers. Each recognizer takes as input the remaining source code, and either fails or outputs the recognized initial string and the corresponding token. If multiple recognizers produce output, the output of the recognizer matching the largest part of the input string is used. Tie-breaking is performed by a priority assigned to each recognizer. For example, the source code string if will be lexed as TKeyword KIf as opposed to TIdentifier “if”, as the keyword recognizer has a greater priority.

The recognizer data types are as follows:

and a single recognize step takes a list of such RecognizerPriority, the source code string, and either fails or outputs the recognized initial string and corresponding token:

Regular expression engine

Internally, the recognizers make use of regular expressions to match strings. The regular expression engine implementation is based on Thompson’s construction [thompson1968programming,xing2004minimized]. In this construction, the regular expression engine compiles a regular expression to a non-deterministic finite automaton (NFA). Here, the compilation is implemented similarly to the main compiler as separate processes of lexing, parsing, and “code” generation in the form of building the NFA. The compiled NFA can subsequently be simulated on an input string, returning all matching strings.

The NFAs are implemented as machines taking string input, and have a set of states, a set of transitions between states, an initial state, and a set of accepting states. Four transition types are implemented: transitions from one state to another predicated on an input character, a conditional transition with an arbitrary predicate on characters, an empty transition, and a transition if the end of the input string has been reached.

The regular expression engine supports the following regular expression constructs:

• the basics: union |, concatenation, literals , and the Kleene closure;
• the option operator (“0 or 1 times”) ?;
• characters sets (“one of …”) [a-zA-Z0-9_!];
• negative character sets (“none of …”) [^a-z];
• escaping of control characters (“literal ‘?’”) \?; and
• the end-of-string marker $.

Many contemporary regular expression engines are implemented using some form of complex recursion, e.g. through parser combinators [cox2007regular]. As such, they are built using a construct able to recognize more expressive types of languages, such as the context-free grammar, as opposed to pure regular expressions. In contrast, NFAs and regular expressions are equivalent regarding the types of languages they can recognize. Thus, Thompson’s construction generally results in a better-performing implementation of regular expressions. For example, compiling the following regular expression

and matching it with

takes 58 seconds using Python’s regular expression implementation on my machine, and only 0.7 seconds using the implementation created for this compiler.

Constructing recognizers

The following illustrates some of the recognizers used and how to construct them:

Parsing

Parsing &SPL proceeds after the lexing phase. The input to the parser is a list of tokens. The parsing phase is aimed at transforming tokens into a more direct representation of the program structure. For example, an expression using a binary operator will have associated with it the specific operator and two sub-expressions, where each sub-expression can be arbitrarily large, resembling a tree structure. As such, the parser transforms the tokens into an abstract syntax tree, and is implemented using a recursive top-down implementation with parser combinators, provided by the Haskell library Parsec.

Abstract syntax tree

At a high level, the &SPL abstract syntax tree consists of declarations (auxiliary source code includes, class declarations, variable declarations and function declarations), statements (such as control structures), expressions (actual calculations) and constants. The &SPL abstract syntax tree is represented naturally as an algebraic data type in Haskell, e.g.:

The types are implemented to keep track of AST meta-information; namely the original source code position for error messages, and the resulting data type of the underlying tree:

Parser implementation

Using parser combinators, the parser closely mimics the defined grammar. For example, 'while' '(' ')' '' is implemented as follows:

However, not all elements of the original grammar are translated so readily. The defined grammar is ambiguous; e.g. it does not inherently make explicit whether 1 + 2 * 4 should be parsed as (1 + 2) * 4 or as 1 + (2 * 4). As such, on top of the the AST data structure we further define operator precedence and associativity rules:

for which we can implement an expression parser as:

Pretty printing

Based on the abstract syntax tree, &SPL source code can automatically be pretty printed. For example,