From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from orbyte.nwl.cc ([151.80.46.58]:53952 "EHLO orbyte.nwl.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753369AbeBSRJp (ORCPT ); Mon, 19 Feb 2018 12:09:45 -0500 Date: Mon, 19 Feb 2018 18:09:39 +0100 From: Phil Sutter To: David Miller Cc: laforge@gnumonks.org, fw@strlen.de, daniel@iogearbox.net, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, alexei.starovoitov@gmail.com Subject: Re: [PATCH RFC 0/4] net: add bpfilter Message-ID: <20180219170939.GF15918@orbyte.nwl.cc> References: <20180219145935.GE6333@breakpoint.cc> <20180219.101335.8419642951000951.davem@davemloft.net> <20180219152746.GH5490@nataraja> <20180219.103139.2230101523652161323.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180219.103139.2230101523652161323.davem@davemloft.net> Sender: netdev-owner@vger.kernel.org List-ID: Hi David, On Mon, Feb 19, 2018 at 10:31:39AM -0500, David Miller wrote: > From: Harald Welte > Date: Mon, 19 Feb 2018 16:27:46 +0100 > > > On Mon, Feb 19, 2018 at 10:13:35AM -0500, David Miller wrote: > > > >> Florian, first of all, the whole "change the iptables binary" idea is > >> a non-starter. For the many reasons I have described in the various > >> postings I have made today. > >> > >> It is entirely impractical. > > > > Why is it practical to replace your kernel but not practical to replace > > a small userspace tool running on top of it? > > The container is just userspace components. Those are really baked in > and are never changing. Which is a problem per se. Cheap hardware routers are a good example of why business models which tend to get customers stuck with old software have such dramatic effects at least in matters of security. > The hosting element, on the other hand, can upgrade the kernel in that > scenerio no problem. > > This is how cloud hosting environments work. What puzzles me about your argumentation is that you seem to propose for the kernel to cover up flaws in userspace. Spinning this concept further would mean that if there would be an old bug in iproute2 we should think of adding a workaround to rtnetlink interface in kernel because containers will keep the old iproute2 binary? Or am I (hopefully) just missing your point? Cheers, Phil