netdev - Re: [PATCH RFC] r8169: straighten out overlength frame detection (v3)

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: <20100105213856.GB24245@hmsreliant.think-freely.org>
Date:	Tue, 5 Jan 2010 16:38:56 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org,
	romieu@...zoreil.com
Subject: Re: [PATCH RFC] r8169: straighten out overlength frame detection (v3)

On Tue, Jan 05, 2010 at 12:40:40PM -0800, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@...il.com>
> Date: Tue, 05 Jan 2010 16:15:53 +0100
> 
> > If hardware is buggy, driver should focus on security first,
> > performance doesnt matter in this case.
> 
> Copying every packet is way too much of a performance hit to
> accept.
> 
> Things are not so black and white, there are shades of grey.
> 
> We can fix this without making things so slow, try harder...
I think thats what I've done in my third version of the patch here.  By raising
the copybreak value, and setting an initial allocation size of 16k, we:

1) close the security hole by default
2) allow for smaller allocations during run time (allocations of the recevied
frame size, rather than 16k every time)
3) Give the user an out if they need the added performance. They have a module
option to lower the copybreak thrshold, and changing the mtu to a different
value will reset the rx allocation size, and frame filter value (and issue a big
warning that doing so may be dangerous)

As we determine which hardware id's are buggy, we can start blacklisting them
specifically, ejoining them from making mtu changes at all, and when we are
confident we have identified all the buggy hardware, we can flip the default
behavior to allocate a resonable frame size and set a good copybreak threshold
for anything not on the blacklist.

Regards
Neil

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