netdev - Re: [RFC PATCH] accounting for socket backlog

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: <1267410585.9082.115.camel@edumazet-laptop>
Date:	Mon, 01 Mar 2010 03:29:45 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Zhu Yi <yi.zhu@...el.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Shi, Alex" <alex.shi@...el.com>
Subject: Re: [RFC PATCH] accounting for socket backlog

Le lundi 01 mars 2010 à 10:17 +0800, Zhu Yi a écrit :
> On Fri, 2010-02-26 at 21:12 +0800, Eric Dumazet wrote:
> > Well, if you have one processor, and a process doesnt want to yield
> > the cpu (apart of sofirq of course that is filling the backlog while
> > your process tries to empty it), your machine is dead. This is
> > critical too :) 
> 
> If you only have one CPU, this won't happen. Because while the receiver
> is busy processing the backlog, no senders will have the chance to be
> scheduled to Tx more. And with the limited backlog, it won't take long
> for the receiver to finish processing all the frames in the backlog.
> 

You focus on the case you Intel guys discovered the flaw, using loopback
interface. I am concerned with a DOS situation, when some bad guys on
your LAN sends a flood on your machine, using a real 10Gb NIC.

I was concerned by two things :

- One process being stuck forever in the __release_sock(), basically
stopping an application from performing progress. This is a DOS problem.
Our kernel is potentially affected. We probably should do something to
avoid this problem. But I am _not_ saying this should be done by your
patch, it is probably possible to address it in an independant patch.

- One process being stuck in __release_sock() and not yield to other
processes. This is not the case since we call the cond_resched_sofirq()
function that permits other high priority task to get the CPU.


One more point :

If you remember my previous mail, I suggested cleaning the len field in
__release_sock(). This way, you can provide a first patch, protocol
agnostic, then provide further patch for UDP V4, another patch for UDP
V6, etc... to have a clean path and make the resolution of the bugs more
self explaining and not as a whole and big patch.
 
Thanks


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