Nftables: a new packet filtering engine

Posted Mar 26, 2009 1:37 UTC (Thu) by gdt (subscriber, #6284)
In reply to: Nftables: a new packet filtering engine by job
Parent article: Nftables: a new packet filtering engine

My immediate worries are that Using a byte code interpreter in the kernel is a very dangerous path. It's like a do-everything-syscall, opaque and hard to understand.

I think a byte code interpreter would be more secure than the current situation, where people who want to get a particular protocol supported have to write a netfilter module. If you think the user-space documentation for iptables hasn't been maintained for years, well the netfilter documentation is much worse. Compared with new kernel authors writing modules which can access any kernel memory or service using under-documented APIs -- a byte code interpreter looks sane: it limits the memory accessed, it talks the language of networking rather than the kernel, it has a limited API, and it has no locking or other kernel-specific difficulties.

Sure, a byte code interpreter makes it possible to do the wrong thing with a syscall. But that wrong thing can't do anything but access and manipulate packets. It can't cause the kernel to crash and die like a poor netfilter module.

to post comments

Nftables: a new packet filtering engine

Posted Mar 26, 2009 17:06 UTC (Thu) by samroberts (subscriber, #46749) [Link] (4 responses)

BPF as used by tcpdump is already a byte-code interpreter in the kernel,
and pre-existed iptables. It does matching, but doesn't have actions.

I find it interesting that the lwn article and what little info I saw
about nftables doesn't either. It seems sufficiently similar, why isn't
it being used as a basis for the opcode interpreter? NIH?

And why the firewalling didn't take a BPF-like approach with an opcode
interpreter and user-space compiler from the start is beyond me.

Nftables: why it isn't based on BPF

Posted Mar 27, 2009 6:55 UTC (Fri) by speedster1 (guest, #8143) [Link]

From Patrick's blog entry (mentioned in article)
http://people.netfilter.org/kaber/weblog/2008/08/20/

A very important feature, one that is missing from all other filters that are built similar in the kernel (like BPF, TC u32 filter, ...), is reconstruction of high level constructs from the representation within the kernel. TC u32 for example allows you to specify "ip daddr X", but when dumping the filter rules it will just display an offset and length.

Nftables: a new packet filtering engine

Posted Mar 27, 2009 18:14 UTC (Fri) by kaber (guest, #18366) [Link] (1 responses)

The BPF interpreter isn't too useful for this case since you can't update an BPF program incrementally and the filter size is limited to 64k. Its also too limited in many other aspects.

Nftables: a new packet filtering engine

Posted Mar 28, 2009 17:21 UTC (Sat) by yoduh (guest, #38527) [Link]

Can you elaborate on these differences for us fresh readers of the bpf-usenix93 paper? Your VM sounds close enough to BPF++ to perhaps describe it in those terms. Both limitations you cite (no incremental update, 64k) sound like implementation decisions made when the goal was picking 1 in 100000 packets, not disposition of every one of them; ie not hard limits.

Nftables: a new packet filtering engine

Posted Apr 3, 2009 18:22 UTC (Fri) by trasz (guest, #45786) [Link]

Actually, at least in FreeBSD, bpf is not just a bytecode interpreter - it employs JIT.