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]

Message-ID: <20090430163200.GC15170@cuplxvomd02.corp.sa.net>
Date:	Thu, 30 Apr 2009 09:32:00 -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 03:44:06PM -0700, David Miller wrote:
> From: David VomLehn <dvomlehn@...co.com>
> Date: Wed, 29 Apr 2009 15:28:09 -0700
> 
> > Still, let us back up to technical specifics.
> 
> The specifics are that if you showed me something that
> added a "u16", at most, I'd go to bat for you and support
> your work going upstream.
> 
> We could find a way to squeeze that into the existing
> structure with little or even no size increase.

I think the size is very doable. Only two bits are needed to encode the state
so the ability to check the state isn't an issue. The other piece, though,
is recording enough information to be able to pinpoint the problem. 

This initial patch uses two void * to record the addresses where the sk_buff
allocation and freeing is done. So, the question is how to compress these.
Since there are only a limited of places where sk_buffs are allocated and
freed, we can, use an index. As long the two indices use a total of no more
than 14 bits, the sk_buff growth will only be 16 bits.

Converting from call location index to the call location is only done when
an error is detected; the performance is not that important. Converting from
a call location to an index is performance critical and I'm thinking of a
couple of approaches. As seems to usually be the case, the better performing
solution is more complex.

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