linux-kernel - RE: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or nmi

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, 06 Jun 2012 10:30:12 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	"Luck, Tony" <tony.luck@...el.com>,
	"Yu, Fenghua" <fenghua.yu@...el.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Ingo Molnar <mingo@...e.hu>, H Peter Anvin <hpa@...or.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	Arjan Dan De Ven <arjan@...ux.intel.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	x86 <x86@...nel.org>, linux-pm <linux-pm@...r.kernel.org>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Subject: RE: [PATCH 0/6] x86/cpu hotplug: Wake up offline CPU via mwait or
 nmi

On Wed, 2012-06-06 at 00:09 +0200, Thomas Gleixner wrote:
> > I don't think so. Its perfectly fine to get TLB invalidate IPIs or
> 
> No it's not. It's silly. I've observed the very issue more than once
> and others have done as well. 
> 
> If you have a process which has N threads where each thread is pinned
> to a core. Only one of them is doing file operations, which result in
> mmap/munmap and therefor in TLB shoot down IPIs even if it's ensured
> that the other pinned threads will never ever touch that
> mapping. That's a PITA as the workaround is to use NFS (how
> performant) or split the process into separate processes with shared
> memory to avoid the sane design of a single process where the
> housekeeping thread just writes to disk.
> 
> This is exactly one of the issues where the application has more
> knowlegde than the kernel and there is no way to deal with it.

But simply refusing IPIs just because isn't going to work either.
Suppose the RT thing did touch the memory region.. then you'll end up
with stale TLB entries, those are not fun either.

We simply cannot not send TLB invalidates, me must assume userspace is
malicious - such is the burden of a general purpose kernel.

The only solution here is using multiple processes and shared memory.
--
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/