linux-kernel - Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

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:	Thu, 5 Apr 2012 16:40:06 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Tejun Heo <tj@...nel.org>
cc:	Mike Galbraith <mgalbraith@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Menage <paul@...lmenage.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

On Thu, 5 Apr 2012, Tejun Heo wrote:

> > We could still move to a single hierarchy, though, if we introduced a 
> > change to allow PF_THREAD_BOUND to attach to both cpusets and cpu iff 
> > its bound cpu is allowed and then do -EINVAL if its changed while still 
> > attached.
> 
> Yeah, making the affected controllers to deal with them somehow
> definitely is an option and will probably have to be chosen for some
> other cases too (e.g. rt tasks).

For cpusets, it's easy if update_nodemask() iterates over threads and 
finds if any PF_THREAD_BOUND thread is bound to a cpu that is disallowed 
by the new nodemask.

It's a very typical configuration to have threads within a cpuset attached 
to a set of mems to use sched_setaffinity() for a subset of those cpus as 
well.  A PF_THREAD_BOUND thread is then perfectly legitimate in a cpuset 
where its cpu intersects with the set of mems but with the above 
restriction that update_nodemask() fails with -EINVAL if its changed to be 
disjoint.

> I still feel lukewarm about the
> ability to put kthreadd to !root cgroup tho.  I mean, for any kind of
> sane accounting, forked kthreads would have to be further classified
> and where kthreadd lives and fork happens wouldn't matter all that
> much.

Forked kthreads may not have to be further classified if the memcg cgroup, 
for example, is mounted after boot and you want to track the memory usage 
of all workqueues or kmem incurred by certain syscalls that don't get 
attributed to the thread calling the syscall because the memory allocation 
is done by a kthread.

The problem is that I'm not in a position to say what everybodys use-case 
is or isn't so I'm biased toward unnecessarily restricting it unless 
absolutely necessary (for cpusets and cpu _until_ we move in the direction 
where update_nodemask(), for example, can fail when PF_THREAD_BOUND 
threads are attached).

I'd also hate to see a cgroup come along in the future, perhaps for 
security where you can only access certain portions of a thread's state if 
they are in the same cgroup, where this will make even more sense beyond 
memcg and cpuacct and then we get into a discussion about why kthreadd is 
prohibited and need to recall this discussion that it's only really 
cpusets and cpu.

> It feels like we're fussing over stuff which isn't that
> significant either way.
> 

Well, I'm fussing over it because the patch being considered unnecessary 
requires that kthreadd can't be moved anywhere and I know one company is 
trying to move in a direction where nothing is in the root memcg.
--
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/