codesize: netfilter/iptables vs. nftables

codesize: netfilter/iptables vs. nftables

[Christoph A.]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

Hi,

from my understanding of the initial announcement of nftables [1]

unlike the iptables kernel approach, nftables does not have a 1-to-1
mapping of matches with modules in the kernel and provides only basic
functionality/operations, userspace can use to combine to build
matches/rules. (intelligence moves from kernel to userspace)

[1]
http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/28922

When creating new matches/targets in iptables one must create the
appropriate ipt/xt_<match> module for the kernel plus the userspace
module  libipt/libxt_<match>.

With the generic way in which a nftables kernel handles data / provides
functions I would assume that this approach of supporting new matches
would change, and one must only create new combinations of kernel
provided operations which does not require kernel code modifications.
The kernelcode size of nftables would be constant regardless of how many
matches it supports.
Is this assumption correct?

Another thing I would like to know is the current codesize of
netfilter/iptables (including ip6tables and ebtables modules) compared
to nftables kernelsize (sloc) (although the current featureset may defer)


I compared them like this:

1. step:
count lines with sloccount in the following directories:
net/ipv4/netfilter/
net/ipv6/netfilter/
net/bridge/netfilter/
net/netfilter/

(gives me 802 files and 62462 SLOC)

2. step:
count lines in the same directories but only including files starting
with nft_*

(62 files and 2288 SLOC)

3. step:
subtraction:
sloc_step1
sloc_step2
(62462 - 2288 = 60174)

netfilter/iptables: 60174 SLOC
only nft_ files: 2288 SLOC
(using nft-2.6 87f619abc27c38583abbf7268319c3f105bf09fd)

this is only correct if nftables does not depend on any code already
present in non nft_* files and I guess this is not correct...(?)

thanks in advance
Christoph A.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: codesize: netfilter/iptables vs. nftables

[Patrick McHardy]

Christoph A. wrote:
> Hi,
> 
> from my understanding of the initial announcement of nftables [1]
> 
> unlike the iptables kernel approach, nftables does not have a 1-to-1
> mapping of matches with modules in the kernel and provides only basic
> functionality/operations, userspace can use to combine to build
> matches/rules. (intelligence moves from kernel to userspace)
> 
> [1]
> http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/28922
> 
> When creating new matches/targets in iptables one must create the
> appropriate ipt/xt_<match> module for the kernel plus the userspace
> module  libipt/libxt_<match>.
> 
> With the generic way in which a nftables kernel handles data / provides
> functions I would assume that this approach of supporting new matches
> would change, and one must only create new combinations of kernel
> provided operations which does not require kernel code modifications.
> The kernelcode size of nftables would be constant regardless of how many
> matches it supports.
> Is this assumption correct?

It depends on the type of match. A new match of packet payload
for instance would likely not need any kernel changes. A new match
on data so far not supported at all would need changes to collect
that data. Once you are able to access a datum, you can combine it
with the existing features in any way you like, f.i. use for
comparisons, range comparisons, set lookups, maps, assignments, ...

> Another thing I would like to know is the current codesize of
> netfilter/iptables (including ip6tables and ebtables modules) compared
> to nftables kernelsize (sloc) (although the current featureset may defer)
> 
> 
> I compared them like this:
> 
> 1. step:
> count lines with sloccount in the following directories:
> net/ipv4/netfilter/
> net/ipv6/netfilter/
> net/bridge/netfilter/
> net/netfilter/
> 
> (gives me 802 files and 62462 SLOC)
> 
> 2. step:
> count lines in the same directories but only including files starting
> with nft_*
> 
> (62 files and 2288 SLOC)

That both seems wrong :) The diffstat of my nft-2.6 tree currently
shows:

 77 files changed, 7824 insertions(+), 258 deletions(-)

but some of that are just API changes touching other files. The
real code size currently is roughly 7300 lines I would guess, the
number of files is somewhere around 25.

> 3. step:
> subtraction:
> sloc_step1
> sloc_step2
> (62462 - 2288 = 60174)
> 
> netfilter/iptables: 60174 SLOC
> only nft_ files: 2288 SLOC
> (using nft-2.6 87f619abc27c38583abbf7268319c3f105bf09fd)
> 
> this is only correct if nftables does not depend on any code already
> present in non nft_* files and I guess this is not correct...(?)

Both use conntrack, NAT, the logging infrastructure and some more.

Re: codesize: netfilter/iptables vs. nftables

[Jan Engelhardt]

On Tuesday 2009-08-11 12:24, Christoph A. wrote:
>
>unlike the iptables kernel approach, nftables does not have a 1-to-1
>mapping of matches with modules in the kernel and provides only basic
>functionality/operations, userspace can use to combine to build
>matches/rules. (intelligence moves from kernel to userspace)
>The kernelcode size of nftables would be constant regardless of how many
>matches it supports.
>Is this assumption correct?

Certain fundamentals do require kernel support such as "store this
in the nfmark now" or "store this in the ctmark now". This won't
change. (See Patrick's reply too.)

What iptables currently does is ask the kernel to match on tcp,
but it could very well ask "check byte X in the network header
for 6" to test for tcp. That is what nftables does, and there is
also xt_u32 for iptables.

>Another thing I would like to know is the current codesize of
>netfilter/iptables (including ip6tables and ebtables modules) compared
>to nftables kernelsize (sloc) (although the current featureset may defer)
>
>I compared them like this:
>
>1. step:
>count lines with sloccount in the following directories:
>net/ipv4/netfilter/
>net/ipv6/netfilter/
>net/bridge/netfilter/
>net/netfilter/

With that you would be counting Conntrack and NAT too, which is not
useful in the comparison. And realistically, counting all extensions
too perturbs the statistics, since iptables, right now, _can_ do
more (TPROXY, just to name one).

Hence I counted by

	net/{bridge,ipv4,ipv6,}/netfilter/*tables.c
	net/{bridge,ipv4,ipv6}/netfilter/*table_{filter,raw,security,mangle}.c

Something like that. iptables clocks in at some 9 kLOC IIRC (~5k
after my large consolidation), and nftables somewhere at 2.5k, but
that's only because I have not yet started trimming down ebtables.

Re: codesize: netfilter/iptables vs. nftables

[Christoph A.]

[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]

thanks your replies

On 11.08.2009 15:53, Patrick McHardy wrote:
> but some of that are just API changes touching other files. The
> real code size currently is roughly 7300 lines I would guess, the
> number of files is somewhere around 25.

at the end I would like to now how many loc has the netfilter/iptables
subsystem(*)  (of a iptables-only kernel) and how many  loc has the
netfilter/nftables(**) subsystem (of a nftables-only kernel) (rawly)

*includes: {ip,ip6,eb,x}tables

**includes: nftables

I hope this is reasonable.

On 11.08.2009 18:53, Jan Engelhardt wrote:
> Hence I counted by
>
> 	net/{bridge,ipv4,ipv6,}/netfilter/*tables.c
> 	net/{bridge,ipv4,ipv6}/netfilter/*table_{filter,raw,security,mangle}.c


is it ok to add net/netfilter/x_tables.c to this list?

>
> Something like that. iptables clocks in at some 9 kLOC IIRC (~5k
> after my large consolidation), and nftables somewhere at 2.5k, but
> that's only because I have not yet started trimming down ebtables.


ok, here my second attempt:

for the iptables part I used a vanilla 31rc4
http://git.kernel.org/?p=linux/kernel/git/kaber/nft-2.6.git;a=commit;h=4be3bd7849165e7efa6b0b35a23d6a3598d97465

cp
{bridge,ipv4,ipv6}/netfilter/*table{s,_filter,_raw,_security,_mangle}.c
 netfilter/x_tables.c /tmp/31rc4/

ls /tmp/31rc4/|wc -l
15

sloccount /tmp/31rc4/
Creating filelist for 31rc4
Computing results.

SLOC	
8834  <==


for nftables I used
http://git.kernel.org/?p=linux/kernel/git/kaber/nft-2.6.git;a=commit;h=a80c1f56e68fd0a7a57a82c85ff50a96a4e38267

find . -name 'nf_table*' -exec cp -i {} /tmp/nftables/ \;
find . -name 'nft_*' -exec cp -i {} /tmp/nftables/ \;
ls /tmp/nftables|wc -l
25  (conforming to the number mentioned by Patrick)

sloccount  /tmp/nftables
Creating filelist for nftables
Computing results.

SLOC
4697	<==


at the end it comes to:
8834 LOC vs. 4697 LOC


for sure this is another flawed comparison but hopefully a better one
than the previous ;)

thanks
Christoph A.


just for the record:

ls /tmp/31rc4/
arptable_filter.c  ebtable_filter.c  ip6table_filter.c  ip6table_raw.c
ip6table_security.c  iptable_mangle.c  ip_tables.c         x_tables.c
arp_tables.c       ebtables.c        ip6table_mangle.c  ip6_tables.c
iptable_filter.c     iptable_raw.c     iptable_security.c

ls /tmp/nftables
nf_table_nat_ipv4.c    nf_tables_bridge.c  nft_bitwise.c    nft_ct.c
         nft_immediate.c  nft_meta.c         nft_reject_ipv4.c
nf_table_route_ipv4.c  nf_tables_core.c    nft_byteorder.c
nft_expr_template.c  nft_limit.c      nft_meta_target.c
nf_table_route_ipv6.c  nf_tables_ipv4.c    nft_cmp.c        nft_exthdr.c
        nft_log.c        nft_payload.c
nf_tables_api.c        nf_tables_ipv6.c    nft_counter.c    nft_hash.c
         nft_lookup.c     nft_rbtree.c



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]