linux-kernel - Re: [PATCH] perf/x86: check ucode before disabling PEBS on SandyBridge

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: <4FD8B5DB.9080209@zytor.com>
Date:	Wed, 13 Jun 2012 08:46:35 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Borislav Petkov <bp@...64.org>,
	Stephane Eranian <eranian@...gle.com>,
	linux-kernel@...r.kernel.org, andi@...stfloor.org, mingo@...e.hu,
	ming.m.lin@...el.com, "Yu, Fenghua" <fenghua.yu@...el.com>
Subject: Re: [PATCH] perf/x86: check ucode before disabling PEBS on SandyBridge

On 06/13/2012 08:37 AM, Peter Zijlstra wrote:
>>
>> perf might, but I have seen such frankensystems in the field and they
>> work (although I haven't seen that particular combo, I have to admit.)
> 
> Thing is, if we boot on the wsm, perf could fault the system with
> nonexistent MSR accesses, if we boot on the nhm worst is wrong numbers I
> think.
> 
> I'm not really inclined to 'fix' this.. the best I'm willing to accept
> is a patch that would detect this situation and simply disable all
> hardware perf support for the platform.
> 

BIOS is *supposed* to pick the least capable CPU as the BSP.  BIOS
being, well, BIOS is known to not always do that, but on the other hand
it is apparently common enough that at least *some* BIOSes are known to
pay attention and do so.

Anyway, I'm not suggesting we should go out of our way to make perf work
on these systems.  Most likely, as you point out, it is either "just
going to work" or totally fail.

What I don't want to see is creating a new facility and encouraging
people to use it, when it is known to be in error.  I'm trying to find
out at the moment just where the practical cutoff is.

	-hpa
--
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/