From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@vger.kernel.org, fw@strlen.de
Subject: Re: [PATCH nft] src: perform sub-byte length matching from the evaluation step
Date: Sat, 28 Nov 2015 19:01:29 +0100 [thread overview]
Message-ID: <20151128180129.GA31884@salvia> (raw)
In-Reply-To: <20151128132023.GC17106@macbook.localdomain>
On Sat, Nov 28, 2015 at 01:20:23PM +0000, Patrick McHardy wrote:
> On 28.11, Pablo Neira Ayuso wrote:
> > I'm not working on the protocol definition problem:
> > http://marc.info/?l=netfilter-devel&m=144862242521205&w=2, but I also
> > need this gets fixed. Let me know if you will be looking into this, just
> > to avoid overlap.
>
> It kinds of depends on the sub-byte handling, so we should get this done
> first.
Looking into this.
> From my previous work on this I still have this patch, which allows you to
> generate an rshift to get the payload to offset 0, then transfers it to the
> LHS during binop simplification if its used in a relational expression.
>
> The upside is that is generic and reuses what we already have.
I like the shift approach based on binop transfer.
But I think this will not to cover this case, on IPv6 the DSCP field
is split between two bytes.
4 bits 6 bits
+-+-+-+-+-+-+-+-+-+-+
| vers | dscp |
+-+-+-+-+-+-+-+-+-+-+
|
1st bytes | 2nd byte
So 4 bit are on the 1st byte and 2 bit are placed on the second byte.
I think this needs a binary-and to get rid of the bits that we dont
need from the 1st and 2nd byte, in this case I'm not sure we can use
your transfer trick.
> The load masking should IMO not be done in eval but netlink_linearize.
I think we can't handle the following case with this approach, eg.
ip dscp & 0xf == 0xf
then we get two bitwise in the code generation:
payload
bitwise
bitwise
cmp
If we perform that transformation from the evaluation step, we can
merge those two bitwise into one.
> We don't even know yet if the payload expression is actually used in
> a relational expression or f.i. in a statement, where handling needs
> to be different.
But these two cases, payload expression and statement, I think they
need different handling both for evaluation and code generation.
For payload statements, the bitwise will need to be retain the bits
that we don't want to mangle, then inclusive-OR them with the value
that we want to set, ie.
r1 = payload(offset, base, len)
r1 = bitwise(r1, AND, mask)
r1 = bitwise(r1, OR, r2)
payload_set(r1, ...)
Cheers,
Pablo
prev parent reply other threads:[~2015-11-28 18:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-28 12:50 [PATCH nft] src: perform sub-byte length matching from the evaluation step Pablo Neira Ayuso
2015-11-28 13:20 ` Patrick McHardy
2015-11-28 18:01 ` Pablo Neira Ayuso [this message]
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=20151128180129.GA31884@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).