linux-kernel - Re: [PATCH] x86 microcode: work_on_cpu and cleanup of the synchronization logic

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]

Date:	Fri, 24 Apr 2009 13:23:57 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Dmitry Adamushko <dmitry.adamushko@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Peter Oruba <peter.oruba@....com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86 microcode: work_on_cpu and cleanup of the 
 synchronization logic

On Fri, 24 Apr 2009, Dmitry Adamushko wrote:
> 2009/4/23 Hugh Dickins <hugh@...itas.com>:
> >
> > I guess your mutex Synchronization works out, but are interrupts
> > still disabled around the critical wrmsr()s, wherever they're getting
> > called from?
> 
> Yes, *msr() calls are only done from functions that are now being
> called via smp_call_function_single(). The later seems to always do it
> with disabled interrupts. The only exception is mc_sysdev_resume()
> calling  ->apply_microcode() directly but this one in turn is always
> called with disabled interrupts.
> 
> But now that you mentioned it I wonder if we may actually need a
> spinlock there... can we have multi-threaded cpus/cores with (all |
> some) shared msr registers?

Good thinking, yes we can and do, unless I'm misinterpreting the
evidence.  Though P4 Xeon and Atom startup messages give the opposite
impression, claiming to update all cpus from lower revision, more
careful tests starting from "maxcpus=1" and then "echo 1 >online"
(which, unless you've fiddled around putting the microcode_ctl'ed
microcode.dat into /lib/firmware/intel-ucode/wherever, isn't able
to update at online time on Intel) shows that the later onlined
siblings already have the updated microcode applied to their
previously onlined siblings.  Which isn't surprising, but I'd
been lulled into thinking the opposite by the startup sequence.

Please add "HT versus not" to my earlier list of confusions.

microcode_mutex still covers most cases: is it the case of onlining
two threads at the same time that slips through?  Is that permitted
at the outer level?  Though even if it is, I'd feel safest to have
the spin_lock_irqsaves back (or if not, comment to say why not needed).

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