linux-kernel - Re: [PATCH 1/3] epoll: increase default max_user

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Jan 2009 21:59:02 +1100
From:	Bron Gondwana <brong@...tmail.fm>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Ray Lee <ray-lk@...rabbit.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Bron Gondwana <brong@...tmail.fm>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] epoll: increase default max_user_instances to 1024

On Wed, Jan 28, 2009 at 10:16:41AM +0000, Alan Cox wrote:
> > It's really simple. A kernel upgrade in a -stable series point release
> > broke a rational user-space setup. If you don't want to adjust the
> 
> You can just as equally load the description the other way:

Only if you're ignoring reality.

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

How about "A kernel upgrade in a -stable series replaced one potential
DoS with another DoS and provided a tunable knob to select which DoS you
would prefer, defaulting to the opposite of the previous behaviour"

> Which is not to say that a smarter limit isn't needed.

Yeah, I have an idea about that, but I need to see if it's actually
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.

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.

I'd be much happier if we could remove the dichotomy of "allow the DoS
or live with a highly crippled epoll implementation until some of the
biggest daemons out there change their usage patterns" (thinking
particularly of java 1.6 and apache here.  Largish postfix installations
are much rarer)

Bron.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/