All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>, f@calendula
Cc: netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: Re: nftables; key update with symbolic values/immediates
Date: Wed, 24 May 2023 09:50:01 +0200	[thread overview]
Message-ID: <ZG3Bqcz3Dru4xOBS@calendula> (raw)
In-Reply-To: <20230523172931.GB17561@breakpoint.cc>

Hi Florian,

On Tue, May 23, 2023 at 07:29:31PM +0200, Florian Westphal wrote:
> Hello.
> 
> Consider following example:
> 
> table ip t {
> 	set s {
> 		type ipv4_addr . ipv4_addr . inet_service
> 		size 65535
> 		flags dynamic, timeout
> 		timeout 3h
> 	}
> 
> 	chain c1 {
> 		update @s { ip saddr . 10.180.0.4 . 80 }
> 	}
> 
> 	chain c2 {
> 		ip saddr . 1.2.3.4 . 80 @s goto c1
> 	}
> }
> 
> This doesn't work:
> :13:14-20: Error: Can't parse symbolic invalid expressions
> ip saddr . 1.2.3.4 . 80 @s goto c1
> 
> Problem is that expr_evaluate_relational() first evaluates
> the lhs, so by the time concat evaluation encounters '1.2.3.4'
> symbol there is nothing that would hint at what datatype that is.
> 
> For this specific case, its possible to first evaluate the rhs, i.e.:
> 
> --- a/src/evaluate.c
> +++ b/src/evaluate.c
> @@ -2336,8 +2336,15 @@ static int expr_evaluate_relational(struct eval_ctx *ctx, struct expr **expr)
>         struct expr *range;
>         int ret;
>  
> +       right = rel->right;
> +       if (right->etype == EXPR_SYMBOL &&
> +           right->symtype == SYMBOL_SET &&
> +           expr_evaluate(ctx, &rel->right) < 0)
> +               return -1;
> +
> 
> This populates ectx->key and thus allows to infer the symbolic data
> type:
> 
> 1485                 if (key) {
> 1486                         tmp = key->dtype;
> 1487                         dsize = key->len;
> 1488                         bo = key->byteorder;
> 1489                         off--;
> 1490                 } else if (dtype == NULL || off == 0) {
> 1491                         tmp = datatype_lookup(TYPE_INVALID);
> 
> line 1486ff.  With unmodified nft, this hits the 'dtype == NULL' path
> and decoding "1.2.3.4" fails.
> 
> What do you think?  If you think this is fine I can work on this,
> above patch makes nft parse the example above, it needs more work on
> delinarization path.

If you have a use-case for this, go ahead.

Is there any other issue you can forecast on the delinearize path? Or
is it just that the code to handle this is missing?

Thanks.

  reply	other threads:[~2023-05-24  7:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 17:29 nftables; key update with symbolic values/immediates Florian Westphal
2023-05-24  7:50 ` Pablo Neira Ayuso [this message]
2023-05-24 11:34   ` Florian Westphal
2023-05-24 13:23   ` [PATCH nft] src: permit use of constant values in set lookup keys Florian Westphal

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=ZG3Bqcz3Dru4xOBS@calendula \
    --to=pablo@netfilter.org \
    --cc=f@calendula \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    /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.