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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ