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]
Message-ID: <20151110153746.GA20758@rabbit.intern.cm-ag>
Date:	Tue, 10 Nov 2015 16:37:46 +0100
From:	Max Kellermann <mk@...all.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	cgroups@...r.kernel.org, cyphar@...har.com, lizefan@...wei.com,
	hannes@...xchg.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cgroup_pids: add fork limit

On 2015/11/10 16:12, Tejun Heo <tj@...nel.org> wrote:
> On Tue, Nov 10, 2015 at 03:06:46PM +0100, Max Kellermann wrote:
> > This patch introduces a new setting called "fork_remaining".  When
> > positive, each successful fork decrements the value, and once it
> > reaches zero, no further forking is allowed, no matter how many of
> > those processes are still alive.  The special value "unlimited"
> > disables the fork limit.
> > 
> > The goal of this limit is to have another safeguard against fork
> > bombs.  It gives processes a chance to set up their child processes /
> > threads, but will be stopped once they attempt to waste resources by
> > continuously exiting and cloning new processes.  This can be useful
> > for short-lived processes such as CGI programs.
> 
> But what's the resource here?

CPU consumption and memory bandwidth.  A fork/clone is an operation
that puts considerable load on a machine, most of which happens in
kernel space (copying page tables etc.).

> All first-order resources which can be consumed by forking
> repeatedly already have proper controllers.

They do?

I can limit CPU time with RLIMIT_CPU, but that's per-process and thus
completely useless.  There's no cgroup controller with such a feature.
There's "cpu" which changes priority, "cpuset" selects CPUs, "cpuacct"
only does accounting and "freezer" (somewhat related).  But nothing
that limits CPU usage according to configured rules.

I can limit absolute memory usage with memcg, which is a good thing,
but is orthogonal to this feature.  Note that there are already
various RLIMITs about memory usage, and despite that, memcg was
merged due to RLIMIT shortcomings.

"pids" was merged even though there already was RLIMIT_NPROC.  Again,
RLIMITs have their shortcomings.

But which controllers can I use to achieve the same effect as my fork
limit feature?  Did I miss one?

> What's the point of adding an extra second-order controller?

I explained that, and you just cited my explanation.

> Where do we go from there?  Limit on the number of syscalls?

No idea.  Are these questions really relevant for my patch?

Max
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ