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

Powered by blists - more mailing lists