Messages in this thread | | | Date | Thu, 29 Jan 2009 07:51:19 +1100 | From | Bron Gondwana <> | Subject | Re: [PATCH 1/3] epoll: increase default max_user_instances to 1024 |
| |
On Wed, Jan 28, 2009 at 08:52:51AM -0800, Davide Libenzi wrote: > On Wed, 28 Jan 2009, Vegard Nossum wrote: > > > On Wed, Jan 28, 2009 at 6:32 AM, Bron Gondwana <brong@fastmail.fm> wrote: > > > That's clearly not happening here - so it seems that maybe our "happy > > > medium" is actually in closer inspection of what's going on rather than > > > a blanket low N to keep N^2 down. > > > > Mh, could another solution to this all be to limit the number times > > you can add a single epoll descriptor to another descriptor's set? > > In the example that was posted, a single fd was added a single time inside > the other 1000+ fds. Epoll already has detection for too long chains and > closed loops, but you can't put those in the fast path. And epoll_ctl() is > one of those.
Not even if you're adding an epoll watcher inside another epoll watcher?
The problem I have here is that "a single fd was added a single time inside the other 1000+ fds" is different behaviour to the daemons out there. They're pretty much all using flat layouts:
process 1: epoll_watcher: leaf fd leaf fd 2 leaf fd 3 leaf fd 4 ...
process 2: epoll_watcher: ...
While the attack happens inside a single process.
Indeed, if you had a _per_process_ watcher limit, you would stop the attack working while not breaking at least postfix and apache. I'm not sure what Java's doing under the hood, I have a feeling it's more thready.
But most of all a way of detecting between a leaf fd and an epoll watcher fd in epoll_ctl and doing deeper tests if it's an epoll watcher that's being added would stop the attack.
Bron.
| |