netdev - Re: [PATCH RFC 0/4] net: add bpfilter

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:   Mon, 19 Feb 2018 09:44:51 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     laforge@...monks.org
Cc:     daniel@...earbox.net, netdev@...r.kernel.org,
        netfilter-devel@...r.kernel.org, alexei.starovoitov@...il.com
Subject: Re: [PATCH RFC 0/4] net: add bpfilter

From: Harald Welte <laforge@...monks.org>
Date: Mon, 19 Feb 2018 13:52:18 +0100

>> Right, having a custom iptables, libiptc or LD_PRELOAD approach would work
>> as well of course, but it still wouldn't address applications that have
>> their own custom libs programmed against iptables uapi directly or those
>> that reused a builtin or modified libiptc directly in their application.
> 
> How many of those wide-spread applications are you aware of?  The two
> projects you have pointed out (docker and kubernetes) don't. As the
> assumption that many such tools would need to be supported drives a lot
> of the design decisions, I would argue one needs a solid empircal basis.

I see talk about "just replacing the iptables binary".

A long time ago in a galaxy far far away, that would be a reasonable
scheme.  But that kind of approach won't work in the realities of
today.

You aren't going to be able to replace the iptables binary in the tens
of thousands of container images out there, nor the virtualization
installations either.

Like it or not iptables ABI based filtering is going to be in the data
path for many years if not a decade or more to come.  iptables is a
victim of it's own success, like it or not :-) Yes, the ABI is
terrible, but obviously it was useful enough for lots of people.

Therefore it behooves us to accept this reality and align the data
path generated to match what the rest of the kernel is moving towards
and that is eBPF and XDP.

Furthrmore, on a long term maintainence perspective, it means that
every data path used by the kernel for iptables will be fully verified
by the eBPF verifier.  This means that the iptables data path will be
guaranteed to never get into a loop, access out of bounds data, etc.

That to me is real power, and something we should pursue.

This doesn't even get into the offloading and other benefits that are
possible.  I know you can't see how offloading is possible, but I hope
are some further discussion you can see how that might work.

Thanks.