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]

Message-ID: <Pine.LNX.4.64.0904241612180.1612@blonde.anvils>
Date:	Fri, 24 Apr 2009 16:30:18 +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:
> 
> Assumption: most of the CPUs (maybe with an exception of the boot-cpu
> when its ucode is updated by BIOS) upgrade from revisions A to B,
> where A and B are the same for all of them (well, at least B -- the
> most recent one [*]).
> 
> Then why bother loading/traversing firmware (or traversing .dat files)
> for each of them?
> 
> [*] btw., are all CPUs on SMP systems similar wrt model, stepping?

I'm not an authority on these matters, but I think it's true to say:
that's almost always the case in practice, and some vendors refuse to
support combinations of non-identical CPUs; but it's not necessarily
the case.  I think there was a product from one vendor (SGI??) which
most commonly had a mixture.

> 
> Even if not, we could do some caching so that if cpu-2 asks for
> intel-ucode/06-0f-0a and we know that cpu-1 has just done the same and
> still has a proper ucode in its buffer, then we just make a copy.

Okay, but don't spend too much code and ingenuity upon it.  And note
that when Intel get around to it (and the distros have caught up),
they will be moving away from the all-in-one /etc/microcode.dat
MICROCODE_OLD_INTERFACE, to the /lib/firmware/intel-ucode/06-0f-0a
style - so I don't think optimizing .dat read time is worth much.

Indeed, MICROCODE_OLD_INTERFACE is driven by /sbin/microcode_ctl
anyway, I don't think you should be second-guessing what it might
feed you.

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/