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.

-