netdev - Re: nftables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <49C0A710.8050207@trash.net>
Date:	Wed, 18 Mar 2009 08:47:28 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Varun Chandramohan <varunc@...ux.vnet.ibm.com>
CC:	Netfilter Developer Mailing List 
	<netfilter-devel@...r.kernel.org>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: nftables

Varun Chandramohan wrote:
> Iam interested in hooking nftables to TC. Could you elaborate on this
> a little bit?
> And when you talk about in-kernel mangle table i suppose you mean the
> mangle table of iptables? 

OK first about mangle - usually tables with nftables should be created
by userspace. The mangle table contains special functionality that needs
to be implemented in the kernel (rerouting), so nftables (just as iptables)
includes some code and table definitions for this. The way it should be is
that rerouting is just a property that can be optionally specified for a
chain.

About TC - thats one of the more complicated things I suppose. The first
thing that needs to be investigated is whether hooking it natively (meaning
it is called directly, similar to the TC classifiers today) or through a TC
classifier would make more sense. The second approach is definitely less
intrusive, but the TC classifier is pretty much useless with nftables
and it imposes some undesirable limits. In the end each class should offer
a chain to attach rules to. I'd also suggest to have a table-like container
for each qdisc, so chains can be added that are not attached directly to
classes (which I'm not sure is possible when using a TC classifier).

What's further needed is:

- a way to transport the nftables netlink attributes to the kernel.
  Either encapsulated in TC attributes or the "normal" way, depending
  on how it is hooked.

- nftables needs to be taught about TC verdicts. Classes bound to the
  classifier should be treated similar to nftables chains (meaning a
  lookup is made and the reference is stored). Check out nft_data_init()
  for reference.

- the ruleset evaluation function probably needs to be split into a
  generic part, dealing with internal flow control, and the netfilter/
  TC specific part, dealing with netfilter verdicts and class IDs.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html