linux-kernel - Re: [RFC] remove netpoll receive code

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] [day] [month] [year] [list]

Message-ID: <20071022165423.GG17536@waste.org>
Date:	Mon, 22 Oct 2007 11:54:23 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Andrew Morton <akpm@...l.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] remove netpoll receive code

[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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/