netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer
@ 2018-03-04 19:40 Florian Westphal
  2018-03-04 19:40 ` [RFC,POC 1/3] bpfilter: add experimental IMR bpf translator Florian Westphal
                   ` (3 more replies)
  0 siblings, 4 replies; 12+ messages in thread
From: Florian Westphal @ 2018-03-04 19:40 UTC (permalink / raw)
  To: netdev; +Cc: daniel, ast, pablo

These patches, which go on top of the 'bpfilter' RFC patches,
demonstrate an nftables to ebpf translation (done in userspace).
In order to not duplicate the ebpf code generation efforts, the rules

iptables -i lo -d 127.0.0.2 -j DROP
and
nft add rule ip filter input ip daddr 127.0.0.2 drop

are first translated to a common intermediate representation, and then
to ebpf, which attaches resulting prog to the XDP hook.

IMR representation is identical in both cases so therefore both
rules result in the same ebpf program.

The IMR currently assumes that translation will always be to ebpf.
As per previous discussion it doesn't consider other targets, so
for instance IMR pseudo-registers map 1:1 to ebpf ones.

The IMR is also supposed to be generic enough to make it easy to convert
'fronted' formats (iptables rule blob, nftables netlink) to it, and
also extend it to cover ip rule, ovs or any other inputs in the future
without need for major changes to the IMR.

The IMR currently implements following basic operations:
 - Relational (equal, not equal)
 - immediates (32 and 64bit constants)
 - payload with relative addressing (macr, network, transport header)
 - verdict (pass, drop, next rule)

Its still in early stage, but I think its good enough as
a proof-of-concept.

Known differences between nftjit.ko and bpfilter.ko:
nftjit.ko currently doesn't run transparently, but thats only
because I wanted to focus on the IMR and get the POC out of the door.

It should be possible to get it transparent via the bpfilter.ko approach.

Next steps for the IMR could be addition of binary operations for
prefixes ("-d 192.168.0.1/24"), its also needed e.g. for tcp flag
matching (-p tcp --syn in iptables) and so on.

I'd also be interested in wheter XDP is seen as appropriate
target hook.  AFAICS the XDP and the nftables ingress hook are similar
enough to consider just (re)using the XDP hook to jit the nftables ingress
hook.  The translator could check if the hook is unused, and return
early if some other program is already attached.

Comments welcome, especially wrt. IMR concept and what might be
next step(s) in moving forward.

The patches are also available via git at
https://git.breakpoint.cc/cgit/fw/net-next.git/log/?h=bpfilter7 .

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2018-03-15 20:26 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-04 19:40 [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer Florian Westphal
2018-03-04 19:40 ` [RFC,POC 1/3] bpfilter: add experimental IMR bpf translator Florian Westphal
2018-03-04 19:40 ` [RFC,POC 2/3] bpfilter: add nftables jit proof-of-concept Florian Westphal
2018-03-04 19:40 ` [RFC,POC 3/3] bpfilter: switch bpfilter to iptables->IMR translation Florian Westphal
2018-03-06 14:22 ` [RFC,POC] iptables/nftables to epbf/xdp via common intermediate layer Daniel Borkmann
2018-03-06 16:42   ` Florian Westphal
2018-03-06 17:24     ` Edward Cree
2018-03-06 18:03       ` Florian Westphal
2018-03-06 18:18         ` Edward Cree
2018-03-15 16:13           ` Alexei Starovoitov
2018-03-15 17:00             ` Florian Westphal
2018-03-15 20:26               ` Alexei Starovoitov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).