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: <20120608150938.GI31359@aftab.osrc.amd.com>
Date:	Fri, 8 Jun 2012 17:09:38 +0200
From:	Borislav Petkov <borislav.petkov@....com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	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, Jun 08, 2012 at 04:45:18PM +0200, Peter Zijlstra wrote:
> I was thinking about reload_store(), that seems to only reload ucode for
> a single cpu.

Ok.

> > > The 'bestestet' idea I came up with is doing the verify thing I have
> > > from a delayed work -- say 1 second into the future. That way, when
> > > there's lots of cpus they all try and enqueue the one work, which at
> > > the end executes only once, provided the entire update scan took less
> > > than the second.
> > 
> > You're saying, you want the last CPU that gets to update its microcode
> > gets to also run the delayed work...? Probably, I'd assume ucode update
> > on a single CPU takes less than a second IIUC.
> 
> Nah.. it'll probably be the first. But it doesn't matter which cpu does
> it. So the idea was:
> 
> static void intel_snb_verify_work(struct work_struct *work)
> {
> 	/* do the verify thing.. */
> }
> 
> static DECLARE_DELAYED_WORK(intel_snb_delayed_work, intel_snb_verify_ucode);
> 
> static int intel_snb_ucode_notifier(struct notifier_block *self,
>                                    unsigned long action, void *_uci)
> {
>         /*
>          * Since ucode cannot be down-graded, and no future ucode revision
>          * is known to break PEBS again, we're ok with MICROCODE_CAN_UPDATE.
>          */
> 
>         if (action == MICROCODE_UPDATED)
> 		schedule_delayed_work(&intel_snb_delayed_work, HZ);
> 
>         return NOTIFY_DONE;
> }
> 
> Thus it will queue the delayed work when the work isn't already queued
> for execution. Resulting in the work only happening once a second (at
> most).

Ok, this would probably work - the last cpu that schedules the work should
definitely see ucode version updated on all cpus.

Or, instead of doing the verify thing on each cpu, you could track which
is the last cpu to run the delayed work and do the verify thing only on
it (the other works simply remove a bit from a bitmask or whatever...).

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

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