netdev - Re: [RFC] net: usbnet: prevent buggy devices from killing us

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: <87txq6g0jy.fsf@nemi.mork.no>
Date:	Thu, 24 Jan 2013 14:42:09 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC] net: usbnet: prevent buggy devices from killing us

Oliver Neukum <oneukum@...e.de> writes:

> On Thursday 24 January 2013 13:47:40 Bjørn Mork wrote:
>> Oliver Neukum <oneukum@...e.de> writes:
>> > On Thursday 24 January 2013 12:22:54 Bjørn Mork wrote:
>> >
>> >> Sorry for being daft, but how do I code the "20 among the last 30" part
>> >> there?
>> >
>> > Just by agreeing that you can live with false negatives but not false positives
>> >
>> > if (++counter > 30) {
>> > 	counter = bogus = 0;
>> > } else {
>> > 	if (is_bogus(packet)
>> > 		bogus++;
>> > 	if (bogus > counter/2)
>
> Should probably be something like bogus > counter/2 + 10

right

>> > 		throttle();
>> > }
>> 
>> So, add two new counters to struct usbnet for this?  That seems a little
>> overkill to me, but I don't see how else to implement anything like that.
>
> Memory is cheap.

OK

>> It is still not completely clear to me how the throttling/unthrottling
>> should be done.  It tested with static counters (to avoid having to
>> rebuild everything for this test) and a new EVENT_RX_THROTTLE flag.
>> Still on top of my previous patch just for safety while testing, as I am
>> fed up of having to reboot all the time :-)
>> 
>> Doing the flag test in rx_submit seems simpler than trying to track all
>> the places this is called.  Still checking the dev->done.qlen to be able
>> to unthrottle.
>
> Ideally we would do some error handling. Does the device keep spewing
> zero packets for all eternity?

Yes. The only way to get rid of the bug once it has triggered seems to
be powering the device off/on.  So unthrottling is not important for
this device.  But I guess it will be for other devices with more
temporary problems.



Bjørn
--
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