On Thu, Jan 12, 2023 at 01:02:59PM +0100, Phil Sutter wrote: > On Thu, Jan 12, 2023 at 12:06:55PM +0100, Pablo Neira Ayuso wrote: > > On Thu, Jan 12, 2023 at 11:15:10AM +0100, Phil Sutter wrote: > > > Bump? > > > > > > On Wed, Dec 21, 2022 at 03:22:21PM +0100, Phil Sutter wrote: > > > > Allow for user space to provide an improved variant of the rule for > > > > actual use. The variant in NFTA_RULE_EXPRESSIONS may provide maximum > > > > compatibility for old user space tools (e.g. in outdated containers). > > > > > > > > The new attribute is also dumped back to user space, e.g. for comparison > > > > against the compatible variant. > > > > > > > > While being at it, improve nft_rule_policy for NFTA_RULE_EXPRESSIONS. > > > > Could you split this in two patches? > > Separate the nft_rule_policy_change? Sure! Thanks. > > I still don't see how this is improving the situation for the scenario > > you describe, if you could extend a bit on how you plan to use this > > I'd appreciate. > > I can send you my WiP libnftnl and iptables patches if that helps. > > The approach this patch follows is pretty simple, though: The kernel > will accept NFTA_RULE_ACTUAL_EXPR to override NFTA_RULE_EXPRESSIONS for > use in the live ruleset. When fetching the ruleset, old user space will > ignore NFTA_RULE_ACTUAL_EXPR, so new user space may submit a compatible > variant of the rule in NFTA_RULE_EXPRESSIONS and a modern variant in > NFTA_RULE_ACTUAL_EXPR. so _ACTUAL_EXPR is the modern representation, and _RULE_EXPRESSIONS the old one? Maybe the opposite is better? I mean, no changes in the NFTA_RULE_EXPRESSIONS semantics, these are always the expressions that run in the datapath, and the alternative expression representation is just for backward compatibility? Maybe all this can be handled from _USERDATA? I mean, to add the netlink representation there? > In iptables, when converting a rule from iptables_command_state into > nftnl expressions, I insert all expressions into both > NFTA_RULE_EXPRESSIONS and NFTA_RULE_ACTUAL_EXPR unless an extension does > fancy stuff (e.g. was converted into native expressions). So NFTA_RULE_EXPRESSIONS contains xt compat expression or is it ACTUAL_EXPR? Probably you can just add NFTA_RULE_COMPAT_EXPRS? This new attribute provides a pure xt compat representation? _ACTUAL concept gets me confused. > My test piece is limit match which had to be converted once (see commit > 5de8dcf75941c for details): I add the native expressions to > NFTA_RULE_ACTUAL_EXPR and create a compat "match" expression for > NFTA_RULE_EXPRESSIONS only. What gets me confused is what the kernel actually uses from the datapath. > The kernel will use the native expressions in the ruleset, dumps will > contain the compat "match" expression instead. Both representations should be dumped, right? In my mind, userspace just falls back to my proposed NFTA_RULE_COMPAT_EXPRS in case it cannot decode NFTA_RULE_EXPRESSIONS. Sorry for taking a while to come back here.
