Re: ANNOUNCEMENT: Intel processor microcode security update
On Sun, 08 Sep 2013, shirish शिरीष wrote:
> microcode bundle 1: /lib/firmware/intel-ucode/06-17-0a
> 01/001: sig 0x0001067a, pf mask 0xa0, 2010-09-28, rev 0x0a0b, size 8192
> 01/002: sig 0x0001067a, pf mask 0x11, 2010-09-28, rev 0x0a0b, size 8192
> 01/003: sig 0x0001067a, pf mask 0x44, 2010-09-28, rev 0x0a0b, size 8192
>
> The update is from one of these three binary files and as can be seen
> the pf mask values of each of them are different.
Each of these apply to several processors. See below.
> May I take this opportunity to add a wishlist bug. I would suggest to
> add example commands. Like me there are many users who do not
There are user-level example commands in the manpages, but for the regular
stuff a normal user would need to do.
> understand technicalities or manpage syntax/language per se. Giving
> example commands should also help in broadening the reach of the
> technology and its effectiveness.
Regular users don't need to mess with iucode-tool, it does everything you
need if you just give it "--scan-system" and point it to a file or directory
with lots of microcodes inside ;-)
intel-microcode uses iucode-tool automatically, without user interaction.
Anything else does require that you actually grok very simple binary
algebra, and also section 9.11 of that Intel document. A lot of what
iucode-tool does is relevant only to people who need to mess with microcode
colections, and that won't be a typical user.
Basically:
x86 processors have some registers related to the processor operation called
MSRs.
Intel processors have a *three-bit* field in MSR #17. This is called
"platform id" and also "processor flags" by Intel. Since there is a
cpuid(1) field that is also called "platform id" which is completely
unrelated, I use "processor flags" in iucode-tool/intel-microcode.
So, each processor has an "processor flags" ID that is between 0 and 7
(three bits). That ID is read from MSR 17.
A byte has 8 bits, numbered from 0 to 7. So, an alternative representation
of that "processor flags" ID is to set the respective bit in a byte. Let's
call that "bitmask form". It is the *same* information, just represented in
a different way (that takes 8 bits instead of 3 bits...).
0x prefix -> hexadecimal notation
b suffix -> binary notation
Processor Flags, MSR17 bit mask format
0 (000b) 0x00
1 (001b) 0x01
2 (010b) 0x02
3 (011b) 0x04
4 (100b) 0x10
.. ..
7 (111b) 0x80
That's the "pf=0xZZ" that the kernel informs. It is the "processor flags"
in "bitmask format".
Now, the microcode update has a "pf mask" field that has a bit set if the
respective processor (i.e. one that bit as its "processor flags" in bitmask
format") is compatible with that microcode update.
In the data above about the available microcode updates for signature
0x1067a, you have:
01/001: sig 0x0001067a, pf mask 0xa0, 2010-09-28, rev 0x0a0b, size 8192
This applies to processors with "pf=0x80" and "pf=0x20".
01/002: sig 0x0001067a, pf mask 0x11, 2010-09-28, rev 0x0a0b, size 8192
This applies to processors with "pf=0x10" and "pf=0x01".
01/003: sig 0x0001067a, pf mask 0x44, 2010-09-28, rev 0x0a0b, size 8192
This applies to processors with "pf=0x40" and "pf=0x04".
pf=0x00 is special: it means the processor doesn't have a platform ID, so
the processor will have pf=0x00, and the microcode updates will have a "pf
mask" that is all zeros. In that case, only the signature matters.
Well, I am not that a good teacher, but still I hope the above is a bit
easier to understand than the Intel documentation. But I am not adding
something that extensive to iucode-tool's manpage :-)
And you really don't need to know any of that to use intel-microcode, it is
supposed to do its job automatically. If it doesn't, that's a bug I will
try to fix.
--
"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
Reply to: