Re: [PATCH 1/3] epoll: increase default max_user_instances to 1024

Bron Gondwana
2009-01-28T13:28:42Z

On Wed, Jan 28, 2009 at 11:36:40AM +0000, Alan Cox wrote:
> > > "A kernel upgrade in a -stable series point release fixed a security DoS"
> >
> > Alan, that's a complete load of bollocks. It broke common configurations
> > of java, postfix and apache on real-world machines, causing significant
> > actual denials of service in previously reliable configurations.
>
> It fixed a security DoS. I was merely pointing out that the description
> provided before was bogus, incomplete and loaded.

Not allowing user logins would have fixed that particular security DoS
too. There's a range of pretty destructive things that can "fix" one
issue at the expense of creating others.

This particular choice of fix just happens to have caused at least three
reported (though not to LKML, but I'll post the URLs for the other two
again in a sec) commonly used applications issues. These applications
were using the published API in a way which used to work perfectly
well, and not DoSing the system.

How would you define a regression otherwise? A public and commonly used
API had a new user-space visable error code added that it had never
returned before, and a low enough limit set that this error was seen in
practice by multiple sites.

http://marc.info/?l=fedora-devel-list&m=123134150926934&w=2

http://pero.blogs.aprilmayjune.org/2009/01/22/hadoop-and-linux-kernel-2627-epoll-limits/

> > viable within the code. The DoS works by creating epoll descriptors
> > watching other epoll descriptors, which strikes me as a much less
> > real-world actual use pattern than a bunch of separate daemons with an
> > epoll watcher each.
>
> Deliberate attackers don't have to follow typical usage patterns.

Sure, but if typical usage patterns hit your sensor, then you have false
positives. Adding a DoS sensor that gets false positives is a regression,
and whitewashing it as "fixed a security DoS" is bogus. It did that, but
also more than that, and the more was/is sucky.

> > If it's possible to count watches only if they're added to another epoll
> > instance, then we'd have a metric that still catches the N^2 attack, but
> > doesn't interact with the common non-attacky use-case.
>
> Agreed entirely.

Yeah, enough arguing hey. Let's come up with a real fix that doesn't
give sites the ugly choice between remaining vulnerable to a known DoS
attack or hobbling common programs that aren't actually using that many
resources.

Bron.