Re: DoS attack against TCP services

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

On 13 Mar 2015, at 14:57, Christos Zoulas <christos%zoulas.com@localhost> wrote:

> On Mar 13,  1:08pm, hannken%eis.cs.tu-bs.de@localhost ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
> 
> | This was just an idea ... Maybe
> | 
> | ...xs..timeout * sc->maxunits + 10
> | 
> | and set xs timeout to 1 .. 5 seconds?
> | 
> | I don't think it is possible to make it self adjusting as the
> | sysmon framework doesn't know the drivers timeouts.
> 
> I guess I can clamp the ccb timeout to 60 seconds...

Good.

> | > | > Nevertheless, I think that the big problem with ciss is now
> | > | > fixed (i.e. it will not hang forever anymore)...
> | > | 
> | > | It may still wait longer than 30 seconds with the sme_mutex held
> | > | leading to deadlock.
> | > | 
> | > | We should use a suitable xs timeout vs. events timeout to make it safe,
> | > | either increase the event timeout or decrease the xs timeout.
> | > 
> | > It would be nice if it was safe by default, and it should spam the
> | > kernel if it was late so that we know about it...
> | 
> | Unfortunately it may deadlock BEFORE it finds a non-empty workqueue.
> 
> Can't it just try to acquire the lock and if it fails it spams, and
> does not deadlock? Or even better, finds the driver that blocks it,
> and bumps its timeout? It is annoying to have a monitoring service
> DoS the whole machine...

Suppose sysmon should use a second mutex for workqueue management only.

This way it should be possible to detect a non-empty workqueue,
print a message and stop adding new work.

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)