nftables bytecode interpreter
- Dominant language
- Go
- Stars
- 19.3k
- Forks
- 2k
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 264
Description
### Description
gVisor already supports iptables to enable packet filtering, mangling, NAT, etc. But Linux users are migrating over time to a newer system to support a similar set of features: nftables. ntables is designed to be simpler in implementation than iptables. Whereas a single feature in iptables (e.g. filtering by TCP port) requires implementation in both the kernel and `iptables` userspace binary, nftables provides a generalized kernel virtual machine that runs bytecode. Thus the userspace application worries about generating bytecode (e.g. to get and check the TCP port), while the kernel just runs whatever bytecode it gets. It doesn't know that it's looking at TCP ports. Adding features requires just generating different bytecode.
On most machines `iptables` is symlinked to either `iptables-legacy` or `iptables-nft`. The former is "true" iptables, and the latter is a wrapper around nftables that allows users to write nftables rules using iptables syntax. The `nft` command provides a more "nftables-like" interface to nftables, although most users seemingly use the `nftables-nft` interface.
We should support nftables, which entails a gVisor in-kernel interpreter for nftables bytecode. Later changes will support modifying rules via the NETLINK socket interface.
### Is this feature related to a specific bug?
_No response_
### Do you have a specific solution in mind?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.