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: <20120608210239.GB16470@khazad-dum.debian.net>
Date:	Fri, 8 Jun 2012 18:02:39 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Borislav Petkov <borislav.petkov@....com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Stephane Eranian <eranian@...gle.com>,
	linux-kernel@...r.kernel.org, andi@...stfloor.org, mingo@...e.hu,
	ming.m.lin@...el.com, Andreas Herrmann <andreas.herrmann3@....com>,
	Dimitri Sivanich <sivanich@....com>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: Re: [PATCH] perf/x86: check ucode before disabling PEBS on
 SandyBridge

On Fri, 08 Jun 2012, Borislav Petkov wrote:
> On Fri, Jun 08, 2012 at 03:26:12PM +0200, Peter Zijlstra wrote:
> > On Fri, 2012-06-08 at 12:00 +0200, Peter Zijlstra wrote:
> > > > > Or we could put a hook in the ucode loader.
> > > > 
> > > > I'd really suggest the latter - I doubt this will be our only 
> > > > ucode dependent quirk, going forward ...
> > > 
> > > Yeah, am in the middle of writing that.. 
> > 
> > OK so the micro-code stuff is a complete trainwreck.
> > 
> > The very worst is that it does per-cpu micro-code updates, not machine
> > wide. This results in it being able to have different revisions on
> > different cpus. This in turn makes the below O(n^2) :/
> 
> Reportedly, there are some obscure systems which need different
> microcode versions per CPU:
> 
> http://lkml.indiana.edu/hypermail/linux/kernel/1105.3/01010.html

I wrote that email you linked above.  All it means is that you can have
more than one microcode *type* per system, because you can have more
than one processor type per system.

The lack of per-system microcode handling is, as far as I am concerned,
a rather annoying misfeature, plain and simple.  A per-core interface
that lets you have mismatched microcode across cores of the same type
(i.e. that take the same microcode) is, IMO, a bottomless pit of pain
and suffering which should diediediediedie as soon as possible.

> > Why do we have per-cpu firmware anyway?
> 
> See above.

It just means the firmware core has to do a per-cpu job, not that we
should have mismatched microcodes across the same type of cpus, or even
that we should have the required per-cpu handling of firmware exposed to
the rest of the kernel and the worst of it all, exposed to userspace.

> Actually, the deal here is that you could have received microcode
> already from BIOS and you won't have to necessarily load ucode from
> userspace with the Linux ucode loader.

Or from an enhanced bootloader.  Yes.

> Btw, this is why we wanted to load ucode as early as possible but
> there's no progress on the whole thing right now...

Which is a pity.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/