Hi, The following patchset adds a new infrastructure to validate incremental updates on rulesets. This new validation approach is based on a the following observations: - New rules always require validation since they could come with expressions that are not supported by the basechain type, eg. masquerade on the filter chain. - New rules that jump/goto target chain result in the validation of such target chain and subsequent chains that are connected this target chain. Same applies to new elements that jump/goto target chain. Such target chains that need validation are stored in a validation list. Then, for each chain, the binding graph is used to perform the validation from the commit/abort phase. Sets and chains provide a list of bindings backwards (to reach the basechain) and forward (to validate subsequent chains that are connected to the target chain. The new binding object stores is composed of a tuple that describes the origin set/chain and the target set/chain, valid binding combinations are: 1) chain-to-chain, eg. rule performs jump/goto target chain 2) chain-to-set, eg. rule performs lookup to set (verdict map). 3) set-to-chain, eg. set element performs jump/goto target chain (verdict map) Adding bindings for 1) and 2) is relatively easy, 3) requires a bit more new code to deal with set deletion and aborting new set element, as well as netlink/netns exit path, to release bindings. This patchset uses a hashtable of bindings to look up for existing bindings when adding new jump/goto chain from rules and set elements. Patches #1 and #2 prepare for this infrastructure by disabling chain validation from preparation phase when validation state is _SKIP as well as avoiding a replay of the transaction on EINTR. Patches #3 to #6 add the infrastructure to collect chains that need valudation, add the new binding infrastructure and finally use it. This is passing tests/shell with debugging instrumentation. On my TODO list: - If the hashtable of bindings is per-netns (instead of per table as in this series), then I think that limiting the maximum number of jump/goto chain should be relatively trivial by adding a counter of total existing bindings in this per-netns (as counterproposal to Shaun Brady's patch to limit the number of jumps per-netns). - I did not explore yet the replacement of the (old) set binding logic (struct nft_set_binding) by this new infrastructure. Comments welcome, thanks. Pablo Neira Ayuso (6): netfilter: nf_tables: honor EINTR in ruleset validation from commit/abort path netfilter: nf_tables: honor validation state in preparation phase netfilter: nf_tables: add infrastructure for chain validation on updates netfilter: nf_tables: add new binding infrastructure netfilter: nf_tables: use new binding infrastructure netfilter: nf_tables: add support for validating incremental ruleset updates include/net/netfilter/nf_tables.h | 52 +- net/netfilter/nf_tables_api.c | 800 ++++++++++++++++++++++++++++-- net/netfilter/nft_immediate.c | 25 +- 3 files changed, 844 insertions(+), 33 deletions(-) -- 2.30.2
