[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: DoS attack against TCP services
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)
Main Index |
Thread Index |