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+. -- 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
