All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>, Florian Westphal <fw@strlen.de>,
	netfilter-devel@vger.kernel.org
Subject: Re: [nf-next PATCH v2] netfilter: nf_tables: Introduce NFTA_RULE_ACTUAL_EXPR
Date: Thu, 2 Feb 2023 22:31:58 +0100	[thread overview]
Message-ID: <Y9wrzkablavNnUXl@salvia> (raw)
In-Reply-To: <Y8f4pNIcb2zH9QqZ@orbyte.nwl.cc>

Hi Phil,

On Wed, Jan 18, 2023 at 02:48:20PM +0100, Phil Sutter wrote:
[...]
> The crucial aspect of this implementation is to provide a compatible
> rule representation for old software which is not aware of it. This is
> only possible by dumping the compat representation in the well-known
> NFTA_RULE_EXPRESSIONS attribute.

OK, so NFTA_RULE_EXPRESSIONS contains the xt expressions.

Then, _ACTUAL_EXPR is taken if kernel supports it and these are
expressions that run from datapath, if present.

> This means what is contained in NFTA_RULE_EXPRESSIONS may not be what
> the kernel actually executes. To make this less scary, the kernel should
> dump the actual rule in a second attribute for the sake of verification
> in user space.
>
> While rule dumps are pretty much fixed given the above, there is
> flexibility when it comes to loading the rule:
> 
> A) Submit the compat representation as additional attribute
> 
> This was my initial approach, but Florian objected because the changing
> content of NFTA_RULE_EXPRESSIONS attribute may be confusing:

It is indeed.

> On input, NFTA_RULE_EXPRESSIONS contains the new rule representation, on
> output it contains the compat one. The extra attribute I introduced
> behaves identical, i.e. on input it holds the compat representation
> while on output it holds the new one.
> 
> B) Submit the new representation as additional attribute
> 
> This is the current approach: If the additional attribute is present,
> the kernel will use it to build the rule and leave NFTA_RULE_EXPRESSIONS
> alone (actually: store it for dumps). Otherwise it will "fall back" to
> using NFTA_RULE_EXPRESSIONS just as usual.
>
> When dumping, if a stored NFTA_RULE_EXPRESSIONS content is present, it
> will dump that as-is and serialize the active rule into an additional
> attribute. Otherwise the active rule will go into NFTA_RULE_EXPRESSIONS
> just as usual.

So this is not swapping things, right? Probably I am still getting
confused but the initial approach described in A.

When, dumping back to userspace, NFTA_RULE_EXPRESSIONS still stores
the xt compat representation and NFTA_RULE_ACTUAL_EXPRS the one that
runs from kernel datapath (if the kernel supports this attribute).

[...]
> I am swapping things around in libnftnl - it uses NFTA_RULE_ACTUAL_EXPRS
> if present and puts NFTA_RULE_EXPRESSIONS into a second list for
> verification only. In iptables, I parse both lists separately into
> iptables_command_state objects and compare them. If not identical,
> there's a bug.

Old kernels would simply discard the ACTUAL_ attribute. Maybe _ALT_
standing by alternative is a better name?

Sorry, this is a bit confusing but I understand something like this is
required as you explained during the NFWS.

  reply	other threads:[~2023-02-02 21:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 14:22 [nf-next PATCH v2] netfilter: nf_tables: Introduce NFTA_RULE_ACTUAL_EXPR Phil Sutter
2023-01-12 10:15 ` Phil Sutter
2023-01-12 11:06   ` Pablo Neira Ayuso
2023-01-12 12:02     ` Phil Sutter
2023-01-18 11:58       ` Pablo Neira Ayuso
2023-01-18 13:48         ` Phil Sutter
2023-02-02 21:31           ` Pablo Neira Ayuso [this message]
2023-02-03 13:48             ` Phil Sutter
2023-02-03 15:32               ` Pablo Neira Ayuso
2023-02-03 16:21                 ` Phil Sutter
2023-02-04  9:41                   ` Pablo Neira Ayuso
2023-02-04 21:00                     ` Phil Sutter
2023-02-06  9:52                       ` Pablo Neira Ayuso
2023-02-07 10:43                         ` Pablo Neira Ayuso
2023-02-07 10:56                           ` Phil Sutter
2023-02-16 10:55                             ` Phil Sutter
2023-02-16 11:29                               ` Pablo Neira Ayuso
2023-02-16 12:05                                 ` Phil Sutter
2023-04-26 19:58                                   ` Pablo Neira Ayuso
2023-04-27 10:57                                     ` Phil Sutter
2023-04-27 11:01                                       ` Pablo Neira Ayuso
2023-04-27 11:33                                         ` Phil Sutter
2023-04-27 13:07                                           ` Pablo Neira Ayuso
2023-04-27 22:45                                             ` Phil Sutter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9wrzkablavNnUXl@salvia \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.