netdev - Re: [Patch 1/1][RFC] NETDEV: Find network bugs by validating the sk

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

Date:	Wed, 29 Apr 2009 15:28:09 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [Patch 1/1][RFC] NETDEV: Find network bugs by validating the
	sk_buff state

On Wed, Apr 29, 2009 at 02:53:38PM -0700, David Miller wrote:
> From: David VomLehn <dvomlehn@...co.com>
> Date: Wed, 29 Apr 2009 08:14:40 -0700
> 
> > On Tue, Apr 28, 2009 at 10:30:58PM -0700, David Miller wrote:
> >> 
> >> Sorry, for this to be useful distributions are going to turn it on by
> >> default, and adding 24 bytes to struct sk_buff on 64-bit when we're
> >> trying everything in our power to make it smaller rather than larger
> >> is not acceptable.
> > 
> > That's like saying that any of the kernel debugging options have to be on
> > by default.  I expect that most folks won't want this on unless they are
> > looking for a bug. 
> 
> We don't have networking buffer structure elements that implement
> debugging, and it's for a reason.

Can I assume this is due to the concern, stated below, that distributions will
start turning it on?

> > Right. This is why it depends on KERNEL_DEBUG and why it is off by default.
> 
> All of this is moot if distributions decide to start turning this
> on, and from my experience they will.

This puzzles me.

It will cost performance and memory if distros turn this on, and they
aren't idiots.  How can we know enough to determine for all distributions
whether the paypack is enough to permanently enable a particular kernel
debugging feature?

Still, let us back up to technical specifics. There is a need for kernel
debugging features and experience shows that the networking area is no
exception. So:

	What criteria must network debugging features meet for kernel
	inclusion, considered first as a kernel debugging feature, and
	second, as a non-optional consistency check?

Memory and performance are obvious choices for criteria, what would the
threshholds be here? Are there other criteria?

Note that I'm happy to consider making it *more* expensive to use a feature
if the case can be made that:
1. The feature must not be used in production
2. The feature becomes expensive enough to prevent its use in production

David VomLehn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html