From: Florian Westphal <fw@strlen.de>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Willem de Bruijn <willemb@google.com>,
Pablo Neira Ayuso <pablo@netfilter.org>,
netfilter-devel <netfilter-devel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Florian Westphal <fw@strlen.de>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf
Date: Tue, 6 Dec 2016 01:20:27 +0100 [thread overview]
Message-ID: <20161206002027.GD16819@breakpoint.cc> (raw)
In-Reply-To: <CAF=yD-J-vcQQ_-48xG8qhMuYvLvucCr7SG99rsfJA5-okvhHzA@mail.gmail.com>
Willem de Bruijn <willemdebruijn.kernel@gmail.com> wrote:
> While we're discussing the patch, another question, about revisions: I
> tested both modified and original iptables binaries on both standard
> and modified kernels. It all works as expected, except for the case
> where both binaries are used on a single kernel. For instance:
>
> iptables -A OUTPUT -m bpf --bytecode "`./nfbpf_compile RAW 'udp port
> 8000'`" -j LOG
> ./iptables.new -L
>
> Here the new binary will interpret the object as xt_bpf_match_v1, but
> iptables has inserted xt_bpf_match. The same problem happens the other
> way around. A new binary can be made robust to detect old structs, but
> not the other way around. Specific to bpf, the existing xt_bpf code
> has an unfortunate bug that it always prints at least one line of
> code, even if ->bpf_program_num_elems == 0.
>
> I notice that other extensions also do not necessarily only extend
> struct vN in vN+1. Is the above a known issue?
Yes, I guess noone ever bothered to fix this.
The kernel blob should contain the match/target revision number,
so userspace can in fact see that 'this is bpf v42', but iirc
the netfilter userspace just loads the highest userspace revision
supported by the kernel (which is then different for the 2 iptables
binaries).
But we *could* display message like 'kernel uses revision 2 but I can
only find 0 and 1' or fall back to the lower supported revision without
guess-the-struct-by-size games.
next prev parent reply other threads:[~2016-12-06 0:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 20:28 [PATCH nf-next] netfilter: xt_bpf: support ebpf Willem de Bruijn
2016-12-05 21:06 ` Eric Dumazet
2016-12-05 21:30 ` Florian Westphal
2016-12-05 22:34 ` Pablo Neira Ayuso
2016-12-05 22:40 ` Florian Westphal
2016-12-05 22:59 ` Eric Dumazet
2016-12-05 23:05 ` Pablo Neira Ayuso
2016-12-05 23:00 ` Pablo Neira Ayuso
2016-12-05 23:06 ` Willem de Bruijn
2016-12-05 23:22 ` Pablo Neira Ayuso
2016-12-05 23:29 ` Willem de Bruijn
2016-12-05 23:51 ` Willem de Bruijn
2016-12-06 0:20 ` Florian Westphal [this message]
2016-12-06 22:44 ` Willem de Bruijn
2016-12-05 22:55 ` Daniel Borkmann
2016-12-05 23:01 ` Willem de Bruijn
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=20161206002027.GD16819@breakpoint.cc \
--to=fw@strlen.de \
--cc=daniel@iogearbox.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@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 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).