linux-kernel - Re: Removing per-task TSD? (Re: Tightening up rdpmc permissions?)

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: <20141003200624.GL10583@worktop.programming.kicks-ass.net>
Date:	Fri, 3 Oct 2014 22:06:24 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Erik Bosman <ebn310@....vu.nl>
Subject: Re: Removing per-task TSD? (Re: Tightening up rdpmc permissions?)

On Fri, Oct 03, 2014 at 09:41:30AM -0700, Andy Lutomirski wrote:
> So this is a mess.  I think that any reasonable implementation of
> rdpmc permissions should be per mm, since we perf_event maps are, of
> course, per mm.
> 
> Similarly, any reasonable implementation of rdtsc permissions should
> be per mm, since doing it sensibly involves telling the vdso not to
> use rdtsc, and the vdso is per mm

So far so good.

> Unfortunately, PR_SET_TSC is a per-thread setting.  Implementing this
> correctly looks like it'll require twiddling, or at least thinking
> about, cr4 at switch_mm time *and* when switching tasks, because the
> only sensible way of granting PMC access to a running mm is to
> broadcast a function call to the cpus running that mm.

Confused... now though.

Any cpu can only ever run one mm at the time, and the only way to change
mm on any one cpu is switch_mm(), so having a CR4 write in switch_mm()
will DTRT, no weird broadcasts or anything else required.

Or were you talking about doing the per mm filter while maintaining the
old TIF_NOTSC thing? Then still no broadcasts would be required I think.

> Nonetheless, this is doable.  Either there can be separate context
> switching of CR4.PCE (in switch_mm) and CR4.TSD (in switch_to), or
> there can be some crazy optimization to make it faster.

IFF you want to retain TIF_NOTSC then yes, we'll need both or crazy.

> All of this sucks, so I'll ask a normally verboten question: can we
> just remove PR_SET_TSC entirely?

Fine with me, see more in that thread, I'll try and reply to the right
copy.
--
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/