[RFC] remove netpoll receive code

[RFC] remove netpoll receive code

[Stephen Hemminger]

The netpoll receive code is:
1. Not used by any in-tree features, it is used by kgdb-over-ether.
2. A nice hook for people doing nasty things like private binary network stacks or rootkits.
3. Unsecured by any of the normal firewalling code.

Hopefully all distro's are smart enough to turn it off in their default config *nudge, nudge*.
Doubly true for any distribution that claims to be secure or enterprise ready.

I propose that we take out all the whole netpoll rx path. If/when kgdb gets submitted
a better and alternative receive path can be added.

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [RFC] remove netpoll receive code

[Andrew Morton]

On Wed, 17 Oct 2007 13:21:31 -0700
Stephen Hemminger <shemminger@linux-foundation.org> wrote:

> The netpoll receive code is:
> 1. Not used by any in-tree features, it is used by kgdb-over-ether.
> 2. A nice hook for people doing nasty things like private binary network stacks or rootkits.
> 3. Unsecured by any of the normal firewalling code.
> 
> Hopefully all distro's are smart enough to turn it off in their default config *nudge, nudge*.
> Doubly true for any distribution that claims to be secure or enterprise ready.
> 
> I propose that we take out all the whole netpoll rx path. If/when kgdb gets submitted
> a better and alternative receive path can be added.
> 

umm, let's cc the kgdb maintainer.

Re: [RFC] remove netpoll receive code

[Jason Wessel]

Kgdb has been submitted for inclusion in the mainline kernel at this
point, along with an additional change to the netpoll rx path.

If it is the case that this needs to be implemented in another manner,
that is ok but please do let me know what the plans are for the API so
that the kgdboe code can be adapted.

Thanks,
Jason.



Stephen Hemminger wrote:
> The netpoll receive code is:
> 1. Not used by any in-tree features, it is used by kgdb-over-ether.
> 2. A nice hook for people doing nasty things like private binary network stacks or rootkits.
> 3. Unsecured by any of the normal firewalling code.
>
> Hopefully all distro's are smart enough to turn it off in their default config *nudge, nudge*.
> Doubly true for any distribution that claims to be secure or enterprise ready.
>
> I propose that we take out all the whole netpoll rx path. If/when kgdb gets submitted
> a better and alternative receive path can be added.
>
>   

Re: [RFC] remove netpoll receive code

[David Miller]

From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Wed, 17 Oct 2007 13:21:31 -0700

> I propose that we take out all the whole netpoll rx path. If/when
> kgdb gets submitted a better and alternative receive path can be
> added.

I would like to kill the RX side handling of netpoll too,
but I don't think that's reasonable as kgdb is actively
being pushed for 2.6.25 inclusion.

Andrew is likely to add it to his -mm tree soon and therefore kgdb
will need to work properly now.

The RX netpoll thing has a long precedence, it's been in the tree for
a long time, so we are in some ways stuck with it until we have a
complete replacement facility.  That means we can't yank it out first
and implement the replacement later.

Re: [RFC] remove netpoll receive code

[Andrew Morton]

On Wed, 17 Oct 2007 23:28:38 -0700 (PDT) David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <shemminger@linux-foundation.org>
> Date: Wed, 17 Oct 2007 13:21:31 -0700
> 
> > I propose that we take out all the whole netpoll rx path. If/when
> > kgdb gets submitted a better and alternative receive path can be
> > added.
> 
> I would like to kill the RX side handling of netpoll too,
> but I don't think that's reasonable as kgdb is actively
> being pushed for 2.6.25 inclusion.
> 
> Andrew is likely to add it to his -mm tree soon and therefore kgdb
> will need to work properly now.

git-kgdb.patch has been in there for ages - maybe a year.  Although I
disabled it a week or so ago due to the sheer number of rejects.  Will
bring it back when things settle down a bit.

> The RX netpoll thing has a long precedence, it's been in the tree for
> a long time, so we are in some ways stuck with it until we have a
> complete replacement facility.  That means we can't yank it out first
> and implement the replacement later.

Re: [RFC] remove netpoll receive code

[Stephen Hemminger]

On Thu, 18 Oct 2007 00:02:44 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 17 Oct 2007 23:28:38 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> 
> > From: Stephen Hemminger <shemminger@linux-foundation.org>
> > Date: Wed, 17 Oct 2007 13:21:31 -0700
> > 
> > > I propose that we take out all the whole netpoll rx path. If/when
> > > kgdb gets submitted a better and alternative receive path can be
> > > added.
> > 
> > I would like to kill the RX side handling of netpoll too,
> > but I don't think that's reasonable as kgdb is actively
> > being pushed for 2.6.25 inclusion.
> > 
> > Andrew is likely to add it to his -mm tree soon and therefore kgdb
> > will need to work properly now.
> 
> git-kgdb.patch has been in there for ages - maybe a year.  Although I
> disabled it a week or so ago due to the sheer number of rejects.  Will
> bring it back when things settle down a bit.
> 
> > The RX netpoll thing has a long precedence, it's been in the tree for
> > a long time, so we are in some ways stuck with it until we have a
> > complete replacement facility.  That means we can't yank it out first
> > and implement the replacement later.

How about I work on a better/alternative receive path for kgdb that
can be applied after kgdb is included.  Kgdb could actually be useful
for me :-)

-- 
Stephen Hemminger <shemminger@linux-foundation.org>

Re: [RFC] remove netpoll receive code

[Matt Mackall]

[annoyed as ever about never being cc:ed on this stuff]

On Wed, Oct 17, 2007 at 01:21:31PM -0700, Stephen Hemminger wrote:
> The netpoll receive code is:
> 1. Not used by any in-tree features, it is used by kgdb-over-ether.

And various crashdump over network tools.

> 2. A nice hook for people doing nasty things like private binary network stacks or rootkits.

It's a completely useless hook for a binary network stack. It only
supports UDP and only point to point. And it will have crap
performance. It's much less useful here than, say, TUN/TAP.

It doesn't buy anything for a rootkit either, which will continue to
trivially hide servers in userspace as they already do.

This point is completely FUD.

> 3. Unsecured by any of the normal firewalling code.

This is correct. It also applies to the TX side of things. The point,
of course, is to bypass as much of the stack as possible so that when
the kernel crashes, we're more likely to actually get our netpoll
data.

> I propose that we take out all the whole netpoll rx path. If/when
> kgdb gets submitted a better and alternative receive path can be
> added.

Let's hear about this better alternative first, shall we? I for one am
a little skeptical of its existence. Going through a larger fraction
of the network stack, running softirqs, etc., are all big (potentially
fatal) steps backward from the point of view of a debugger.

-- 
Mathematics is the supreme nostalgia of our time.