Hi,
So here it is: my proposal for a full support of xtables extensions, both with compat layer (match/target expressions) and also with pure nft translation.
(Note that this is only an RFC, since currently: this works only on iptables-nftables built with --enable-static, you will see why.)
Summary
-------
I came up with an idea which required a lot of refactoring, mostly to simplify the code and of course to find a solution for all our problems with xtables extensions.
In short, now process it strictelly following these path:
injecting rules: command line -> command structure -> nft rule -> kernel
reading rules : kernel -> nft rule -> command structure -> listing/saving etc...
The big difference introduced in that patch is reusing the command structure in both ways, and not only for injecting rules.
Result: clearer code, only 1 parsing of the rule expressions is necessary (_that_ is a big change), and of course we can reuse easily existing legacy code.
The nft translation process
---------------------------
Parsing the rule expressions is the key here.
Central place for it: the nft translation engine. This "engine" is a basic tree based pattern matching code.
In short: you register an "instruction" - made of a list of nft expressions - and a parsing function into a instructions tree.
For instance, one of the possible list of nft expressions for retrieving the ip addresses part of a rule is: payload, bitwise, compare.
Thus you can provide such list and a related parsing function to the "instruction tree" and when you will give a rule to be translated through the engine,
if such instructions list is found, it will call the relevant parsing function.
It of course handles the case where a pattern is made of other known smaller patterns: so is the long pattern the one which matches, or the smaller ones?
Such case is handled. The engine takes care of keeping track of all patterns. The policy of "longest pattern found" is applied for deciding which ones matches.
(It matches when the given parsing function returns a success code).
Now that we can express all parts of a rule via such "instructions", parsing function can populate the command structure.
The Xtables extensions
----------------------
Such translation engine has an interest for centralizing the parsing into one object (the command structure), but even more for future port of xtables extensions,
expressed as pure nft expressions.
Currently, nftables provides a compatibility layer to support xtables extensions as there current form: the infamouf memory blob.
But little by little, such memory blobs will be expressed as pure nft expressions list. The most obvious one was DNAT (and SNAT), thus I already implemented such support (last patch)
And there would start the troubles: about 100 of extensions, all expressed in a small subset of nft expressions... go figure which expressions list matches which extensions.
Morever that, on the contrary of current compatibility layer, the extension name is not going to be present at all.
Hopefully, the translation process described above applies perfectly here and solves that issue as well.
Patches
-------
Now the code.
Please review,
Tomasz Bursztyka (15):
xtables: Add support for injecting xtables target into nft rule
-> If a target extensions provides a way to "translate" its blob as pure nft expressions list, let's use it.
xtables: add support for injecting xtables matches into nft rule
-> same for matches extensions
nft: Add nft expressions translation engine as a library
-> Self explainatory. I made it af a library since both the core and the xtalbse extensions can use it.
nft: Integrate nft translator engine in current core
-> That patch is the step to retrieve a command structure from an nft rule, via the translation engine.
nft: Manage xtables target parsing through translation tree
-> Provides an instruction to support xt target expression list in the translation tree
nft: Manage xtables matches through nft translation tree
-> Same for xt match expression list
nft: Add support for xtables extensions callback to change cs
-> This is debatable: xtables extensions have no access to the command structure,
so instead I introduced such callback mecanism.
xtables: Add support for registering nft translation function for
target
-> Hook for registering an instruction into a translation tree, from an xtables target extension.
xtables: Add support for registering nft translation function for
match
-> Same for an xtables match extension
nft: Register all relevant xtables extensions into translation tree
-> That one is debatable, but I needed a way to register relevant extensions (ones providing translation instruction).
Note: This works _only_ if you build with --enable-static. I think it requires another solution, adding a pre_loading
function to libxtables maybe so it could work with shared/static build.
This is the main reason why I send this as an RFC.
nft: Refactor firewall printing so it reuses already parsed cs struct
-> Now we can scrap the old code which was multiple times going through the expression list, and use the command structure
nft: Refactor rule deletion so it compares both cs structure
-> Same but when deleting a rule: let's use the command structur.
nft: Remove useless function
-> Ok that one is a trivial fix, actually I should have send it appart of this patch set.
xtables: nft: Complete refactoring on how rules are saved
-> Same for listing or deleting rule: here again old code is scrapped to be able to use the command structure instead
xtables: Support pure nft expressions for DNAT extension
-> Now here is an example of an extension which can translate its blob into pure nft expressions, and can rebeilt
its blog from nfs expression via registering the right instructions/parsing function as descriped above.
Makefile.am | 3 +
configure.ac | 8 +
extensions/GNUmakefile.in | 1 +
extensions/libipt_DNAT.c | 220 +++++++++++
include/nft-translator.h | 85 ++++
include/xtables.h.in | 14 +
iptables/Makefile.am | 3 +-
iptables/nft-ipv4.c | 125 ++----
iptables/nft-ipv6.c | 81 ++--
iptables/nft-shared.c | 72 +++-
iptables/nft-shared.h | 23 +-
iptables/nft-xt-ext.c | 181 +++++++++
iptables/nft-xt-ext.h | 14 +
iptables/nft.c | 893 +++++++++++++-----------------------------
iptables/nft.h | 8 +-
iptables/xtables-events.c | 21 +-
libnfttrans/Makefile.am | 28 ++
libnfttrans/libnfttrans.pc.in | 11 +
libnfttrans/nft-translator.c | 618 +++++++++++++++++++++++++++++
19 files changed, 1637 insertions(+), 772 deletions(-)
create mode 100644 include/nft-translator.h
create mode 100644 iptables/nft-xt-ext.c
create mode 100644 iptables/nft-xt-ext.h
create mode 100644 libnfttrans/Makefile.am
create mode 100644 libnfttrans/libnfttrans.pc.in
create mode 100644 libnfttrans/nft-translator.c
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
