All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Tom Yan <tom.ty89@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft 2/3] netlink_linearize: incorrect netlink bytecode with binary operation and flags
Date: Thu, 29 Jul 2021 08:55:46 +0200	[thread overview]
Message-ID: <20210729065546.GA15962@salvia> (raw)
In-Reply-To: <CAGnHSEnxcVjN2etN-LNCgpb1h_hmSWMMh3Zm-GqbkZ0XOxCN-w@mail.gmail.com>

On Thu, Jul 29, 2021 at 10:57:35AM +0800, Tom Yan wrote:
> On Wed, 28 Jul 2021 at 05:05, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > A quick summary:
> >
> > - If you want an exact match:
> >
> > tcp flags == fin,syn,ack
> >
> > - If you want to check that those three bits are set on (regardless
> >   the remaining bits):
> >
> > tcp flags fin,syn,ack / fin,syn,ack
> >
> > - If you want to check that any of these three bits is set on:
> >
> > tcp flags fin,syn,ack
> 
> This is exactly what I find absurd btw. IMHO it's much better if the
> latter just means `tcp flags == (fin | syn | ack)`.

Look at this from a different angle, ie. ct state

        ct state new,established

ct state also has a bitmask datatype, and people are not expecting
here to match to new AND established.

> I'd rather we keep `tcp flags & (fin | syn | ack) != 0` and so
> "unsimplified" or accept something like `tcp flags { fin / fin, syn
> / syn, ack / ack }`

The curly brace notation implies the use of sets. Sets only allow for
exact matches, therefore

tcp flags { fin, syn, ack}

is actually making exact matches on the tcp flags.

  reply	other threads:[~2021-07-29  6:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-27 15:37 [PATCH nft 1/3] expression: missing != in flagcmp expression print function Pablo Neira Ayuso
2021-07-27 15:37 ` [PATCH nft 2/3] netlink_linearize: incorrect netlink bytecode with binary operation and flags Pablo Neira Ayuso
2021-07-27 18:36   ` Tom Yan
2021-07-27 21:05     ` Pablo Neira Ayuso
2021-07-29  1:48       ` Tom Yan
2021-07-29  7:03         ` Pablo Neira Ayuso
2021-07-29 10:41           ` Tom Yan
2021-07-29 10:58             ` Tom Yan
2021-07-29 15:16               ` Tom Yan
2021-07-30  4:53                 ` Tom Yan
2021-07-29  2:57       ` Tom Yan
2021-07-29  6:55         ` Pablo Neira Ayuso [this message]
2021-07-27 15:37 ` [PATCH nft 3/3] evaluate: disallow negation with binary operation Pablo Neira Ayuso

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=20210729065546.GA15962@salvia \
    --to=pablo@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=tom.ty89@gmail.com \
    /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.