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

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



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

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

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

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

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
-

On Thu, 18 Oct 2007 00:02:44 -0700

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

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.




-

On Wed, 17 Oct 2007 13:21:31 -0700

umm, let's cc the kgdb maintainer.
-