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]

Message-ID: <20180219152321.GG5490@nataraja>
Date:   Mon, 19 Feb 2018 16:23:21 +0100
From:   Harald Welte <laforge@...monks.org>
To:     David Miller <davem@...emloft.net>
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

Hi David,

On Mon, Feb 19, 2018 at 09:44:51AM -0500, David Miller wrote:
> 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.

I appear to have been under the impression that the entire movement to
DevOps and automatic provisioning of containers/nodes/pods/Vms with
puppet, ansible, Dockerfiles & Co is to be *more* agile in deployments,
rather than less.

If you cannot even rebuild your thousands of container images with
updated binaries, then what is this all worth?  You need to be able to
update the iptables (or any other) binary in case there's an important
(security or otherwise) bug that needs fixing.  I don't see this any
different.

Also, as long as legacy ip_tables/x_tables is still in the kernel, you
can still run your old userspace against that old implementation in the
kernel.  Nobody forces you to use anything else [for another decade or
so].  Just if you want to take advantage of new more
modular/performant/... things like nftables or an eBPF backend, then you
would have to go that extra mile.

I don't think the kernel (network) developers should burden themselves
with too many things.  There's sufficient on their plate as-is.  So 
* if there's some new system (nftables, bpfilter, ...)
* and some documented migration paths for the vast majority of the use
  cases (replacing iptables binaries with a compat wrapper)
* and the old system continues to work as-is (x_tables kernel code stays for
  several more years)

Then people who care about the new features or performance will migrate
to the new system.  And those who don't care stay with the old system -
which is not a problem as they clearly wouldn't need the new system
anyway.

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

I beg to differ.  For some people, yes.  but then, as Florian points
out, they can just as well use the existing x_tables kernel code.  If
they want something better, they can either replace their iptables
program with xtables-compat from nftables, or whatever else might
exist for eBPF support.

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

and it continues to do so.  I just don't think it is a great idea
to kludge any new packet filter against such an arcane uapi.

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

This argument is unrelated to the question of the uapi. I'm not arguing
against an eBPF backend/implementation for packet filtering.  It's more
a question of _how_.

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

Once again, both not related to the question of the uapi.

> I know you can't see how offloading is possible, but I hope
> are some further discussion you can see how that might work.

I'm looking forward to that point.

Regards,
	Harald

-- 
- Harald Welte <laforge@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)