linux-kernel - [patch 00/13] sched/treewide: Clean up various racy task affinity issues

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-next>] [day] [month] [year] [list]

Message-Id: <20170412200726.941336635@linutronix.de>
Date:   Wed, 12 Apr 2017 22:07:26 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     LKML <linux-kernel@...r.kernel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Sebastian Siewior <bigeasy@...utronix.de>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        "David S. Miller" <davem@...emloft.net>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Len Brown <lenb@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, Tejun Heo <tj@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Viresh Kumar <viresh.kumar@...aro.org>
Subject: [patch 00/13] sched/treewide: Clean up various racy task affinity
 issues

While dealing with the fallout of the scheduler cleanups on RT, we found
several racy usage sites of the following scheme:

	cpumask_copy(&save_cpus_allowed, &current->cpus_allowed);
	set_cpus_allowed_ptr(current, cpumask_of(cpu));
	do_stuff();
	set_cpus_allowed_ptr(current, &save_cpus_allowed);

That's racy in two aspects:

1) Nothing prevents the CPU from being unplugged after the temporary
   affinity setting is in place. This results on code being executed on the
   wrong CPU(s).

2) Nothing prevents a concurrent affinity setting from user space. That
   also results in code being executed on the wrong CPU(s) and the restore
   of the previous affinity setting overwrites the new one.

Various variants of cleanups:

 - Removal, because the calling thread is already guaranteed to run on the
   correct CPU.

 - Conversion to smp function calls (simple register read/write)

 - Conversion to work_on_cpu(). There were even files containing comments
   to that effect.

 - The rest needs seperate hotplug protection for work_on_cpu(). To avoid open
   coding the

	get_online_cpus();
	if (cpu_online(cpu))
		ret = do_stuff();
	else
		ret = -ENODEV;
	put_online_cpus();

   scheme this series provides a new helper function work_on_cpu_safe()
   which implements the above.

Aside of fixing these races this allows to restrict the access to
current->cpus_allowed with a follow up series.

Thanks,

	tglx
---
 arch/ia64/kernel/salinfo.c           |   31 ++++-------
 arch/ia64/kernel/topology.c          |    6 --
 arch/ia64/sn/kernel/sn2/sn_hwperf.c  |   16 +++---
 arch/powerpc/kernel/smp.c            |   26 ++++------
 arch/sparc/kernel/sysfs.c            |   36 +++----------
 drivers/acpi/processor_driver.c      |   10 +++
 drivers/acpi/processor_throttling.c  |   31 +++++------
 drivers/cpufreq/ia64-acpi-cpufreq.c  |   91 ++++++++++++++---------------------
 drivers/cpufreq/sh-cpufreq.c         |   45 ++++++++++-------
 drivers/cpufreq/sparc-us2e-cpufreq.c |   45 ++++++++---------
 drivers/cpufreq/sparc-us3-cpufreq.c  |   46 ++++++-----------
 drivers/crypto/n2_core.c             |   31 ++++++-----
 include/linux/workqueue.h            |    5 +
 kernel/workqueue.c                   |   23 ++++++++
 14 files changed, 209 insertions(+), 233 deletions(-)