Re: DoS attack against TCP services

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

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

> On Mar 13,  1:00pm, hannken%eis.cs.tu-bs.de@localhost ("J. Hannken-Illjes") wrote:
> -- Subject: Re: DoS attack against TCP services
> 
> | This would be simple, changing dev/ic/ciss.c like:
> | 
> |         sc->sc_sme->sme_name =3D device_xname(sc->sc_dev);
> |         sc->sc_sme->sme_cookie =3D sc;
> |         sc->sc_sme->sme_refresh =3D ciss_sensor_refresh;
> | +	sc->sc_sme->sme_events_timeout =3D 60;
> | 
> | should do the job.  Unfortunately I have no hardware to test.
> 
> Yes, but is 60 enough? Leaving the calculation to each driver
> is potentially dangerous. Could we make it self adjusting?

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.

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

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