Re: [PATCH iptables 0/4] iptables: Fix [unsupported revision] for matches/targets after update

gt; iptables/iptables.c | 66 +-- > libxtables/xtables.c | 221 +- > 4 files changed, 257 insertions(+), 102 deletions(-) > -- For the series: Acked-by: Willem de Bruijn <will...@google.com> Thanks for fixing this, Serhey. -- To unsubscrib

Re: [PATCH RFC 0/4] net: add bpfilter

> I see several possible areas of contention: > > 1) If you aim for a non-feature-complete support of iptables rules, it >will create confusion to the users. Right, you need full feature parity to be avoid ending up having to maintain two implementations. It seems uncontroversial that BPF

Re: [PATCH] netfilter: add overflow checks in xt_bpf.c

On Thu, Nov 30, 2017 at 11:08 PM, Jann Horn <ja...@google.com> wrote: > On Fri, Dec 1, 2017 at 5:04 AM, Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: >> On Thu, Nov 30, 2017 at 7:46 PM, Jann Horn <ja...@google.com> wrote: >>> Check whether input

Re: [PATCH] netfilter: add overflow checks in xt_bpf.c

On Thu, Nov 30, 2017 at 7:46 PM, Jann Horn wrote: > Check whether inputs from userspace are too long (explicit length field too > big or string not null-terminated) to avoid out-of-bounds reads. > > As far as I can tell, this can at worst lead to very limited kernel heap >

Re: [PATCH] netfilter: xt_bpf: Fix XT_BPF_MODE_FD_PINNED mode of 'xt_bpf_info_v1'

; immediatley after IPT_SO_GET_ENTRIES, by opening a new, > process-local fd per every 'xt_bpf_info_v1' entry seen. > > However, in [2] both Pablo Neira Ayuso and Willem de Bruijn suggested to > depricate the xt_bpf_info_v1 ABI dealing with pinned ebpf objects. > > This fix cha

Re: [PATCH v2 2/2] extensions: xt_bpf: get the pinned ebpf object when match is initialized

ts. > > The file descriptor saved in xt_bpf_info_v1 structure is being re-open > in tc_init_fixup which is invoked immediately after tc_init. > > Signed-off-by: Rafael Buchbinder <r...@rbk.ms> > Signed-off-by: Shmulik Ladkani <shmu...@nsof.io> Thanks a lot for

Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?

On Wed, Sep 13, 2017 at 11:05 AM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt <jeng...@inai.de> wrote: >> >> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote: >>> >>>One way to f

Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?

On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt wrote: > > On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote: >> >>One way to fix is to have iptables open the object (using the stored >>xt_bpf_info_v1->path), gaining a new process local fd for the object, >>just after getting

Re: linux-next: build failure after merge of the netfilter tree

On Wed, May 17, 2017 at 1:02 AM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell <s...@canb.auug.org.au> > wrote: >> Hi all, >> >> After merging the netfilter tree, today's linux-next b

[PATCH nf] xtables: fix build failure from COMPAT_XT_ALIGN outside CONFIG_COMPAT

From: Willem de Bruijn <will...@google.com> The patch in the Fixes references COMPAT_XT_ALIGN in the definition of XT_DATA_TO_USER, outside an #ifdef CONFIG_COMPAT block. Split XT_DATA_TO_USER into separate compat and non compat variants and define the first inside an CONFIG_COMPAT

Re: linux-next: build failure after merge of the netfilter tree

On Tue, May 16, 2017 at 11:45 PM, Stephen Rothwell wrote: > Hi all, > > After merging the netfilter tree, today's linux-next build (i386 > defconfig) failed like this: > > net/netfilter/x_tables.c: In function 'xt_match_to_user': > net/netfilter/x_tables.c:303:13: error:

[PATCH nf] xtables: zero padding in data_to_user

From: Willem de Bruijn <will...@google.com> When looking up an iptables rule, the iptables binary compares the aligned match and target data (XT_ALIGN). In some cases this can exceed the actual data size to include padding bytes. Before commit f77bc5b23fb1 ("iptables: use match, targ

Re: .config for iptables icmp rule delete failure

On Tue, May 9, 2017 at 12:18 AM, Willem de Bruijn <will...@google.com> wrote: > On Mon, May 8, 2017 at 10:22 PM, Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: >> On Mon, May 8, 2017 at 4:22 PM, Florian Westphal <f...@strlen.de> wrote: >>> Ric

Re: .config for iptables icmp rule delete failure

On Mon, May 8, 2017 at 10:22 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Mon, May 8, 2017 at 4:22 PM, Florian Westphal <f...@strlen.de> wrote: >> Richard Guy Briggs <r...@redhat.com> wrote: >> >> [ CC'ing Willem ] >> &g

Re: .config for iptables icmp rule delete failure

On Mon, May 8, 2017 at 4:22 PM, Florian Westphal wrote: > Richard Guy Briggs wrote: > > [ CC'ing Willem ] > >> (Summary of IRC conversation for background...) >> Paul Moore and I hit what appears to be a bug since f25's 4.10.11 and >> upstream's 4.11-rc3 that

Re: [PATCH next] iptables: on revision mismatch, do not call print/save

>> > It may be more subtle than what you describe. xtables_find_match >> > can call xtables_fully_register_pending_match which calls >> > compatible_match_revision to decide whether a match revision >> > is supported and, if multiple revisions are supported, which to prefer. >> >> The case

Re: [PATCH next] iptables: on revision mismatch, do not call print/save

On Wed, Apr 26, 2017 at 5:15 PM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: >>> The patch breaks backward/forward compatibility in a match/target. >>> >>> When the list of the revisions of a given match/target of iptables is not >>> exact

Re: [PATCH next] iptables: on revision mismatch, do not call print/save

>> The patch breaks backward/forward compatibility in a match/target. >> >> When the list of the revisions of a given match/target of iptables is not >> exactly the same as for the kernel counter part (when the kernel module >> supports less revisions than iptables), then in spite of the supported

Re: [PATCH next] iptables: on revision mismatch, do not call print/save

On Fri, Apr 21, 2017 at 4:15 PM, Jozsef Kadlecsik <kad...@blackhole.kfki.hu> wrote: > Hi, > > On Thu, 8 Dec 2016, Willem de Bruijn wrote: > >> From: Willem de Bruijn <will...@google.com> >> >> Between revisions, the layout of xtables data may chang

[PATCH nf-next 4/7] arptables: use match, target and data copy_to_user helpers

From: Willem de Bruijn <will...@google.com> Convert arptables to copying entries, matches and targets one by one, using the xt_match_to_user and xt_target_to_user helper functions. Signed-off-by: Willem de Bruijn <will...@google.com> --- net/ipv4/netfilter/arp_tables.c | 15 +-

[PATCH nf-next 7/7] xtables: extend matches and targets with .usersize

From: Willem de Bruijn <will...@google.com> In matches and targets that define a kernel-only tail to their xt_match and xt_target data structs, add a field .usersize that specifies up to where data is to be shared with userspace. Performed a search for comment "Used internally by

[PATCH nf-next 5/7] ebtables: use match, target and data copy_to_user helpers

From: Willem de Bruijn <will...@google.com> Convert ebtables to copying entries, matches and targets one by one. The solution is analogous to that of generic xt_(match|target)_to_user helpers, but is applied to different structs. Convert existing helpers ebt_make_XXXname helpers that ove

[PATCH nf-next 6/7] xtables: use match, target and data copy_to_user helpers in compat

From: Willem de Bruijn <will...@google.com> Convert compat to copying entries, matches and targets one by one, using the xt_match_to_user and xt_target_to_user helper functions. Signed-off-by: Willem de Bruijn <will...@google.com> --- net/netfilter/x_tables.c | 14 -- 1

[PATCH nf-next 0/7] xtables: use dedicated copy_to_user helpers

From: Willem de Bruijn <will...@google.com> xtables list and save interfaces share xt_match and xt_target state with userspace. The kernel and userspace definitions of these structs differ. Currently, the structs are copied wholesale, then patched up. The match and target structs contain a

[PATCH nf-next 3/7] ip6tables: use match, target and data copy_to_user helpers

From: Willem de Bruijn <will...@google.com> Convert ip6tables to copying entries, matches and targets one by one, using the xt_match_to_user and xt_target_to_user helper functions. Signed-off-by: Willem de Bruijn <will...@google.com> --- net/ipv6/netfilter/ip6_t

[PATCH nf-next 1/7] xtables: add xt_match, xt_target and data copy_to_user functions

From: Willem de Bruijn <will...@google.com> xt_entry_target, xt_entry_match and their private data may contain kernel data. Introduce helper functions xt_match_to_user, xt_target_to_user and xt_data_to_user that copy only the expected fields. These replace existing logic that calls copy_t

[PATCH next] iptables: on revision mismatch, do not call print/save

From: Willem de Bruijn <will...@google.com> Between revisions, the layout of xtables data may change completely. Do not interpret the data in a revision M with a module of revision N. Signed-off-by: Willem de Bruijn <will...@google.com> --- iptables/ip6tables.c | 18 ++--

[PATCH] extensions: libxt_bpf: support ebpf pinned objects

From: Willem de Bruijn <will...@google.com> Exercise the new kernel feature introduced in commit 2c16d6033264 ("netfilter: xt_bpf: support ebpf") to load pinned eBPF programs. The new interface allows instantiating a bpf match using -m bpf --object-pinned ${PATH} wher

Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf

On Mon, Dec 5, 2016 at 7:20 PM, Florian Westphal <f...@strlen.de> wrote: > Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: >> While we're discussing the patch, another question, about revisions: I >> tested both modified and original iptables binaries on bo

[PATCH nf-next v2] netfilter: xt_bpf: support ebpf

From: Willem de Bruijn <will...@google.com> Add support for attaching an eBPF object by file descriptor. The iptables binary can be called with a path to an elf object or a pinned bpf object. Also pass the mode and path to the kernel to be able to return it later for iptables dump an

Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf

On Mon, Dec 5, 2016 at 6:29 PM, Willem de Bruijn <will...@google.com> wrote: > On Mon, Dec 5, 2016 at 6:22 PM, Pablo Neira Ayuso <pa...@netfilter.org> wrote: >> On Mon, Dec 05, 2016 at 06:06:05PM -0500, Willem de Bruijn wrote: >> [...] >>> Eric also sugges

Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf

On Mon, Dec 5, 2016 at 6:22 PM, Pablo Neira Ayuso <pa...@netfilter.org> wrote: > On Mon, Dec 05, 2016 at 06:06:05PM -0500, Willem de Bruijn wrote: > [...] >> Eric also suggests a private variable to avoid being subject to >> changes to PATH_MAX. Then we can indeed also c

Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf

gt;> > > On Mon, 2016-12-05 at 15:28 -0500, Willem de Bruijn wrote: >> > > > From: Willem de Bruijn <will...@google.com> >> > > > >> > > > Add support for attaching an eBPF object by file descriptor. >> > > > >> > &

[PATCH nf-next] netfilter: xt_bpf: support ebpf

From: Willem de Bruijn <will...@google.com> Add support for attaching an eBPF object by file descriptor. The iptables binary can be called with a path to an elf object or a pinned bpf object. Also pass the mode and path to the kernel to be able to return it later for iptables dump an

[PATCH netfilter] extensions/libxt_bpf.man: clarify BPF code generation with tcpdump

From: Willem de Bruijn <will...@google.com> The xt_bpf module applies BPF bytecode to the packet. Depending on where the module is invoked, the kernel may pass a packet with or without link layer header. Iptables has no such header. A common `tcpdump -ddd ` compilation command may