[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.1709131613520.8761@n3.vanv.qr>
Date: Wed, 13 Sep 2017 16:22:13 +0200 (CEST)
From: Jan Engelhardt <jengelh@...i.de>
To: Shmulik Ladkani <shmulik@...f.io>
cc: netfilter-devel@...r.kernel.org,
Pablo Neira Ayuso <pablo@...filter.org>,
netdev@...r.kernel.org, Willem de Bruijn <willemb@...gle.com>,
Rafael Buchbinder <rbk@...f.io>, shmulik.ladkani@...il.com,
eyal@...f.io
Subject: Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?
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 the rules from IPT_SO_GET_ENTRIES.
>However we didn't see any other extensions doing something like that in
>iptables.
>
>Another way to solve is to fix the ABI (or have a v2 one), that does NOT
>pass the fd from userspace, only the path of the pinned object.
>Then, 'bpf_mt_check_v1' will open the file from the given path in order
>to get the bpf_prog.
But a path has a similar problem like a file descriptor - it is local to a
certain mount namespace.
To load "large" blobs into the kernel, a pointer to user memory is a possible
option. The downside is that such extra data is not retrievable from the kernel
via the iptables setsockopts anymore - one could work around it with procfs, or
just let it be.
https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_geoip.c
line 64+.
Powered by blists - more mailing lists