blobs: is there a reason for intel microcode version 20150121?

[Martin Kepplinger]

Since there are many releases of Intel's cpu microcode since 2015-01, I 
was wondering if
there's a reason why coreboot, if at all, uses this one.

I know very little about it really. It may well be potentially bad to 
simply use the latest version,
but in case it's really only because nobody did it, I might prepare a 
patch to use
downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead 
(someday, after
I testing it on my device).

thanks
                                          martin

[Zoran Stojsavljevic]

> I know very little about it really. It may well be potentially bad to

simply use the latest version,
> but in case it's really only because nobody did it, I might prepare a

patch to use
> downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead

(someday, after
> I testing it on my device).

To understand what is really going on, I did the following investigation on
my only coreboot clone version,
I have on my current SSD the following: WIN10, using VMware® Workstation 12
Player, version  12.5.8 build-7098237
with Fedora 26 VM, where the coreboot is located.

CLI transcript follows:

*[user@localhost coreboot]$ pwd*
*/home/user/projects/coreboot/coreboot*
*[user@localhost coreboot]$ git describe*
*4.5-1006-gef7e98a2ac*
*[user@localhost coreboot]$ grep -r 20150121 **
*3rdparty/blobs/cpu/intel/microcode/update-microcodes.sh:MICROCODE_VERSION=20150121*
*[user@localhost coreboot]$ cd 3rdparty/blobs/cpu/intel/microcode*
*[user@localhost microcode]$ ls -al*
*total 24*
*drwxrwxr-x.  2 user user 12288 Nov 21 12:27 .*
*drwxrwxr-x. 24 user user  4096 Feb 18  2017 ..*
*-rwxrwxr-x.  1 user user  1782 Feb 18  2017 microcode2bin.sh*
*-rwxrwxr-x.  1 user user  2989 Nov 21 12:27 update-microcodes.sh*
*[user@localhost microcode]$ tail -10 update-microcodes.sh *
*}*

*get_microcode*
*separate_microcode*
*move_microcode*
*dump_cpuids <<=========================== I added this line of code to see
which CPUIDs's MCUs are added here: *

*rm -f $MICROCODE_ARCHIVE*
*rm -f $MICROCODE_FILE*

*[user@localhost microcode]$ *

Now, you can substitute 20150121.tgz with 20171117
http://downloadmirror.intel.com/27337/eng/microcode-20171117.tgz.tgz in
bash shell script update-microcodes.sh and see what will happen?!

I somehow hope this exercise is helpful.

Zoran

On Tue, Nov 21, 2017 at 9:31 AM, Martin Kepplinger 
wrote:
> Since there are many releases of Intel's cpu microcode since 2015-01, I
> was wondering if
> there's a reason why coreboot, if at all, uses this one.
>
> I know very little about it really. It may well be potentially bad to
> simply use the latest version,
> but in case it's really only because nobody did it, I might prepare a
> patch to use
> downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead
> (someday, after
> I testing it on my device).
>
> thanks
>                                          martin

[Nico Huber]

Hi Martin,

On 21.11.2017 09:31, Martin Kepplinger wrote:
> Since there are many releases of Intel's cpu microcode since 2015-01, I
> was wondering if
> there's a reason why coreboot, if at all, uses this one.

the explanation might be a simple one, e.g. the last person who tried to
update it, didn't know the new package exists at all. I bet that's true
for 99% of the coreboot community.

Last time I checked for microcode updates (for Skylake) I had to click
through a license at intel.com and promise not to redistribute it! And
if you ask Intel employees about it, they just ignore you. So I'm overly
pleased to see your link ;) thank you very much! Please tell us, for
future reference, how you found it.

Now if you also tell us that it comes with a license that allows redris-
tribution, that would be like an early Christmas xD That we don't have
the (mandatory!) updates for current Intel processors in our blobs repo-
sitory is one of the big bummers that make the upstream coreboot ex-
perience suck.
> I know very little about it really. It may well be potentially bad to
> simply use the latest version,

No, it's considered to be the best thing to use the latest updates.
> but in case it's really only because nobody did it, I might prepare a
> patch to use
> downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead
> (someday, after
> I testing it on my device).

Please do so. Though, the `update-microcodes.sh` doesn't fit the binary
format in the new package any more. I guess it can be replaced with a
simpler script, e.g.

for f in ??-??-??; do
        model=$(echo $f | sed -e's/(0.)-(.)(.)-0./0x\2\1\3/')
        dir=$(printf "model_%xx\n" $model)
        mkdir -p $dir
        cat $f >>$dir/microcode.bin
    done

Best,
Nico

[Zoran Stojsavljevic]

> And if you ask Intel employees about it, they just ignore you.

In 99,9% of cases, asking INTEL employees about anything is just pure waste
of the time and effort!

IMHO!

Zoran

On Tue, Nov 21, 2017 at 7:33 PM, Nico Huber  wrote:
> Hi Martin,
>
> On 21.11.2017 09:31, Martin Kepplinger wrote:
> > Since there are many releases of Intel's cpu microcode since 2015-01, I
> > was wondering if
> > there's a reason why coreboot, if at all, uses this one.
>
> the explanation might be a simple one, e.g. the last person who tried to
> update it, didn't know the new package exists at all. I bet that's true
> for 99% of the coreboot community.
>
> Last time I checked for microcode updates (for Skylake) I had to click
> through a license at intel.com and promise not to redistribute it! And
> if you ask Intel employees about it, they just ignore you. So I'm overly
> pleased to see your link ;) thank you very much! Please tell us, for
> future reference, how you found it.
>
> Now if you also tell us that it comes with a license that allows redris-
> tribution, that would be like an early Christmas xD That we don't have
> the (mandatory!) updates for current Intel processors in our blobs repo-
> sitory is one of the big bummers that make the upstream coreboot ex-
> perience suck.
> > I know very little about it really. It may well be potentially bad to
> > simply use the latest version,
>
> No, it's considered to be the best thing to use the latest updates.
> > but in case it's really only because nobody did it, I might prepare a
> > patch to use
> > downloadmirror.intel.com/27337/eng/microcode-20171117.tgz instead
> > (someday, after
> > I testing it on my device).
>
> Please do so. Though, the `update-microcodes.sh` doesn't fit the binary
> format in the new package any more. I guess it can be replaced with a
> simpler script, e.g.
> for f in ??-??-??; do
>     model=$(echo $f | sed -e's/\(0.\)-\(.\)\(.\)-0./0x\2\1\3/')
>     dir=$(printf "model_%xx\n" $model)
>     mkdir -p $dir
>     cat $f >>$dir/microcode.bin
> done
>
> Best,
> Nico