linux-kernel - Re: [PATCH 2/3] x86 perf: Protect LBR msrs accessing against potential #GP

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: <20140801073825.GG19379@twins.programming.kicks-ass.net>
Date:	Fri, 1 Aug 2014 09:38:25 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	kan.liang@...el.com
Cc:	andi@...stfloor.org, alexander.shishkin@...ux.intel.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] x86 perf: Protect LBR msrs accessing against
 potential #GP

On Thu, Jul 31, 2014 at 02:41:02AM -0700, kan.liang@...el.com wrote:
> From: Kan Liang <kan.liang@...el.com>
> 
> Intel PT will take over LBR hardware. If RTIT_CTL.TraceEn=1, any attempt to
> read or write the LBR or LER MSRs, including LBR_TOS, will result in a #GP.
> Intel PT can be enabled/disabled at runtime by hardware/BIOS, so it's better
> LBR MSRs can be protected at runtime.
> 
> The {rd,wr}msrl_goto can protect LBR accessing against the potential #GP.
> Furthermore, it will not impact the "fast" path's performance.

NAK!

I already said this isn't going to ever happen.

Both PT and LBR are arbitrated through the kernel, therefore we can (and
must) deny PT when there's existing LBR usage and vice versa.

We will not hijack resources like this full stop end of story.

Fuck hardware/BIOS, they should _NOT_ be touching this.

The 3 people in the world with access to an x86 hardware debugger had
better be competent and know WTF they're doing and the BIOS can just
piss off right now, they should not be touching this _EVER_.

Content of type "application/pgp-signature" skipped