netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH v6 -next 2/4] netfilter: nftables: add connlabel set support
Date: Mon, 25 Apr 2016 23:34:18 +0200	[thread overview]
Message-ID: <20160425213418.GA1920@salvia> (raw)
In-Reply-To: <20160425170541.GC9987@macbook.localdomain>

On Mon, Apr 25, 2016 at 06:05:41PM +0100, Patrick McHardy wrote:
> On 25.04, Florian Westphal wrote:
> > Patrick McHardy <kaber@trash.net> wrote:
> > 
> > > The alternative to internally handling it would be to some propagating
> > > validation to immediates / sets which invoke the actual user of the data.
> > > So in the case of helpers, we could replace the name by references to
> > > the helper structures and reverse this during dumping.
> > > 
> > > Regarding connlabels this doesn't really apply though. We expect userspace
> > > to create a reasonable ruleset and anything that does not cause critical
> > > errors is validated in userspace.
> > 
> > Yes.  So we have three choices here (pseudo-code)
> > 
> > memcpy(ct->labels, regs->data[priv->sreg], sizeof(reg));
> > vs.
> > set_bit(priv->imm, ct->labels);
> > 
> > The latter is what the iptables module does, I do not mind if we
> > go for #1 (treat the label area just like an 128bit register and
> > replace it completely with whatever is in the source register).
> > 
> > My only problem is that Pablo suggested #2 whereas you recommend #1.
> > 
> > I don't want to resubmit until there is consensus as to what the
> > preferred solution is.
> > 
> > We could go for a 3rd alternative, namely:
> > 
> > u16 bit = regs->data[priv->sreg];
> > set_bit(bit, ct->labels);
> > 
> > i.e. have userspace place the _bit_ that we want to set in the
> > source register.
> > 
> > If we go for sreg that would be my favored solution.
> > 
> > The only drawback vs #1 is that get and set work differently
> > (get places all labels into dreg, set expects bit to set).
> 
> That seems like a problem. I agree that #3 would generally be fine, but
> we should also really have "ct labels set ct labels" not change the labels,
> that would be highly counterintuitive.

'ct labels set' is actually operating a bitwise level.

I suggested to introduce something like:

'ct labels bitset' so the user becomes aware of this operation.

And we can just disallow "ct labels set ct labels" since it doesn't
make sense for what Florian needs AFAIK.

  parent reply	other threads:[~2016-04-25 21:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-21 14:34 [PATCH -next v6] nftables: connlabel set support Florian Westphal
2016-04-21 14:34 ` [PATCH -next 1/4] netfilter: nft_ct: rename struct nft_ct to nft_ct_reg Florian Westphal
2016-04-21 14:34 ` [PATCH v6 -next 2/4] netfilter: nftables: add connlabel set support Florian Westphal
2016-04-25 10:35   ` Patrick McHardy
2016-04-25 10:59     ` Florian Westphal
2016-04-25 11:16       ` Patrick McHardy
2016-04-25 11:56         ` Florian Westphal
2016-04-25 12:16           ` Pablo Neira Ayuso
2016-04-25 12:29             ` Florian Westphal
2016-04-25 17:05           ` Patrick McHardy
2016-04-25 21:19             ` Florian Westphal
2016-04-25 21:35               ` Patrick McHardy
2016-04-25 21:38                 ` Pablo Neira Ayuso
2016-04-25 22:03                   ` Patrick McHardy
2016-04-25 21:54                 ` Florian Westphal
2016-04-26  2:19                   ` Florian Westphal
2016-04-25 21:34             ` Pablo Neira Ayuso [this message]
2016-04-21 14:34 ` [PATCH libnftnl 3/4] ct: " Florian Westphal
2016-04-21 14:34 ` [PATCH nft 4/4] ct: add conntrack label " 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=20160425213418.GA1920@salvia \
    --to=pablo@netfilter.org \
    --cc=fw@strlen.de \
    --cc=kaber@trash.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).