linux-kernel - Re: [RFC] Restrict kernel spawning of threads to a specified set of cpus.

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, 12 Sep 2013 20:30:25 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Gilad Ben-Yossef <gilad@...yossef.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mike Frysinger <vapier@...too.org>,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC] Restrict kernel spawning of threads to a specified set of
 cpus.

On Thu, Sep 12, 2013 at 03:42:21PM +0000, Christoph Lameter wrote:
> Let me just say that the user space approach does not work because the
> kernel sets the cpumask to all and then spawns a thread f.e. for
> usermodehelper.
> 
> This mean we would have to run a daemon that keeps scanning for errand
> threads and then move them. But at that point the damage would already
> have been done. Short term threads would never be caught.
> 
> So I think the kernel based approach is unavoidable.
> 
> Look at this in kernel/kmod.c:
> 
> static int ____call_usermodehelper(void *data)
> {
>         struct subprocess_info *sub_info = data;
>         struct cred *new;
>         int retval;
> 
>         spin_lock_irq(&current->sighand->siglock);
>         flush_signal_handlers(current, 1);
>         spin_unlock_irq(&current->sighand->siglock);
> 
>         /* We can run anywhere, unlike our parent keventd(). */
>         set_cpus_allowed_ptr(current, cpu_all_mask);
> 
> 
> !!!!! No chance to catch this from user space.
> 
> 
> 
> 	....
> 
>         retval = do_execve(sub_info->path,
>                        (const char __user *const __user *)sub_info->argv,
>                            (const char __user *const __user *)sub_info->envp);
>         if (!retval)
> 
> 
> 	....
> 

Yeah, setting the threads affinity is racy from userspace in any case. By the time
one scan /proc for tasks, some others can be forked concurrently.

So yeah it's a problem in theory. Now in practice, I have yet to be convinced because
this should be solved after a few iterations in /proc in most cases.

Now the issue doesn't only concern kthreads but all tasks in the system.
If we really want to solve that race, then may be we can think of a kernel_parameter
that sets the initial affinity of init and then lets get it naturally inherited
through the whole tree.
--
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/