netdev - Re: netfilter: xt_bpf: ABI issue in xt_bpf_info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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