On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt <jengelh@xxxxxxx> 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 the rules from IPT_SO_GET_ENTRIES. >>However we didn't see any other extensions doing something like that in >>iptables. The binary should call bpf_obj_get on the filepath each time. These are not regular files, but references to a pinned object in the bpf filesystem. Blindly passing back the fd received from the kernel is clearly wrong. I'm really surprised that I did not run into this problem when I wrote the feature. >> >>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. Because these are pinned objects in the bpf filesystem, and there is only one of those, it may be possible to lookup the object in the kernel without relying on a process-local view of mount points. > > 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+. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
