When does AMD release the fam15 spectre microcode updates?

They said they would be releasing opteron microcode updates in a few 
weeks but it has been over a month and I am wondering when this is going 
to happen or if it already has and I should re-compile coreboot?

https://www.amd.com/en/corporate/speculative-execution
"We expect to make updates available for our previous generation 
products over the coming weeks."

Thanks!

[Rudolf Marek]

Hi,

There is slight update from AMD [1], relevant part for you:

*AMD Microcode Updates for GPZ Variant 2/Spectre*

In addition, microcode updates with our recommended mitigations addressing 
Variant 2 (Spectre) have been released to our customers and ecosystem partners 
for AMD processors dating back to the first “Bulldozer” core products introduced 
in 2011.

AMD customers will be able to install the microcode by downloading BIOS updates 
provided by PC and server manufacturers and motherboard providers.  Please check 
with your provider for the latest updates.

Unfortnately, I dont know where to get that microcode. Any ideas?

And also, it changed in [2] the claims that IBPB should be made on context switch.

Thanks
Rudolf

[1] https://www.amd.com/en/corporate/security-updates
[2] 
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Updat...

[Rudolf Marek]

Hi,

I found new microcode here [1], I used cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity family15h CPU.
I hacked together a new microcode header which contains the equivalence table etc to be able to load this microcode into the CPU from Linux.

dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 of=header.bin
cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > microcode_amd_fam15h.bin

copy the file to same location and trigger update:

echo 1 >  /sys/devices/system/cpu/microcode/reload

[ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
[ 6032.964913] microcode: CPU2: new patch_level=0x0600111f

Please note that the header.bin does contain a size of the microcode blob, but it happens to be the same, so it works. Normally the container
may contain more microcode blobs. But in my case I use just "right" one for my CPU.

The new microcode seems to be adding the IBPB feature.

Thanks
Rudolf

[1] https://github.com/platomav/CPUMicrocodes

[awokd]

On Tue, April 17, 2018 7:30 am, Rudolf Marek wrote:
> Hi,
>
> I found new microcode here [1], I used
> cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my
> Trinity family15h CPU.
> I hacked together a new microcode header which contains the equivalence
> table etc to be able to load this microcode into the CPU from Linux.
>
> dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84
> of=header.bin cat header.bin
> cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin >
> microcode_amd_fam15h.bin

At what byte locations in the header is the equivalence table? I was
looking for this...

[Rudolf Marek]

Hi,

Dne 17.4.2018 v 12:09 awokd via coreboot napsal(a):
> At what byte locations in the header is the equivalence table? I was
> looking for this...

Hm I'm not aware where is it documented, or if there is some tool to manipulate it/dump the structure. Maybe
it could be added to some existing tool?

Here is what I deduced from Linux arch/x86/kernel/cpu/microcode/amd.c
+ header files

+ 0 u32 UCODE_MAGIC 
+ 4 u32 UCODE_EQUIV_CPU_TABLE_TYPE (0x0)
+ 8 u32 size of following equiv table say "N"

Then this follows, the last table has installed_cpu_cpuid == 0

u32 installed_cpu_cpuid
u32 fixed_errata_mask
u32 fixed_errata_compare
u16 equiv_cpu
u16 res

+ N u32 UCODE_UCODE_TYPE (0x1)
+ N + 4 u32 sizeof blob (without this header)
+ N + 8 microcode blob from github follows here
...
Then after that, there clould be again

+ X u32 UCODE_UCODE_TYPE
+ X + 4 u32 SECTION_SIZE
+ X + 8 microcode header (blob from github follows here)

The microcode blob has the header which already matches the usual microcode header:

struct microcode_header_amd {
        u32     data_code;
        u32     patch_id;
        u16     mc_patch_data_id;
        u8      mc_patch_data_len;
        u8      init_flag;
        u32     mc_patch_data_checksum;
        u32     nb_dev_id;
        u32     sb_dev_id;
        u16     processor_rev_id;
        u8      nb_rev_id;
        u8      sb_rev_id;
        u8      bios_api_rev;
        u8      reserved1[3];
        u32     match_reg[8];
} __attribute__((packed));

Thanks
Rudolf

[awokd]

On Tue, April 17, 2018 10:31 am, Rudolf Marek wrote:
> Hi,
>
> Dne 17.4.2018 v 12:09 awokd via coreboot napsal(a):
> > At what byte locations in the header is the equivalence table? I was
> > looking for this...
>
> Hm I'm not aware where is it documented, or if there is some tool to
> manipulate it/dump the structure. Maybe it could be added to some existing
> tool?

I ran into that too, couldn't find it documented anywhere!
> Here is what I deduced from Linux arch/x86/kernel/cpu/microcode/amd.c
>
> header files
>
> 0 u32 UCODE_MAGIC
>
> 4 u32 UCODE_EQUIV_CPU_TABLE_TYPE (0x0)
>
> 8 u32 size of following equiv table say "N"
>
> Then this follows, the last table has installed_cpu_cpuid == 0
>
> u32 installed_cpu_cpuid u32 fixed_errata_mask u32 fixed_errata_compare u16
> equiv_cpu u16 res
> N u32 UCODE_UCODE_TYPE (0x1)
> N + 4 u32 sizeof blob (without this header)
> N + 8 microcode blob from github follows here
>
> ...
> Then after that, there clould be again
> X u32 UCODE_UCODE_TYPE
> X + 4 u32 SECTION_SIZE
> X + 8 microcode header (blob from github follows here)

Thank you; I'll try to cross-reference against the AGESA code and see if I
can work it out. That was the only way I could get my corebooted system to
recognize my equivalent CPU for microcode updates before.

On 04/17/2018 03:30 AM, Rudolf Marek wrote:
> Hi,
>
> I found new microcode here [1], I used cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity family15h CPU.
> I hacked together a new microcode header which contains the equivalence table etc to be able to load this microcode into the CPU from Linux.
>
> dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 of=header.bin
> cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > microcode_amd_fam15h.bin
>
> copy the file to same location and trigger update:
>
> echo 1 >  /sys/devices/system/cpu/microcode/reload
>
> [ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
> [ 6032.964913] microcode: CPU2: new patch_level=0x0600111f
>
> Please note that the header.bin does contain a size of the microcode blob, but it happens to be the same, so it works. Normally the container
> may contain more microcode blobs. But in my case I use just "right" one for my CPU.
>
> The new microcode seems to be adding the IBPB feature.
>
> Thanks
> Rudolf
>
> [1] https://github.com/platomav/CPUMicrocodes

This didn't work on my piledriver CPU's :[

When I try to "reload" nothing happens not even an error in dmesg....the
reload command has never worked for me no matter what system I use intel
or amd.

Thanks for helping.
I can't believe everyone else is so nonchalant about all this
considering how important it is I still haven't figured out how to
update the microcode on any of my computers - no guides I have found
actually work and no distros have the new microcode for intel or amd
despite it having been months.

For the best security one should have both the new microcode and the
lfence msr?

[Nico Huber]

On 25.04.2018 00:18, [e-mail] wrote:
> On 04/17/2018 03:30 AM, Rudolf Marek wrote:
> > Hi,
> >
> > I found new microcode here [1], I used cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity family15h CPU.
> > I hacked together a new microcode header which contains the equivalence table etc to be able to load this microcode into the CPU from Linux.
> >
> > dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 of=header.bin
> > cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > microcode_amd_fam15h.bin
> >
> > copy the file to same location and trigger update:
> >
> > echo 1 >  /sys/devices/system/cpu/microcode/reload
> >
> > [ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
> > [ 6032.964913] microcode: CPU2: new patch_level=0x0600111f
> >
> > Please note that the header.bin does contain a size of the microcode blob, but it happens to be the same, so it works. Normally the container
> > may contain more microcode blobs. But in my case I use just "right" one for my CPU.
> >
> > The new microcode seems to be adding the IBPB feature.
> >
> > Thanks
> > Rudolf
> >
> > [1] https://github.com/platomav/CPUMicrocodes
>
> This didn't work on my piledriver CPU's :[
>
> When I try to "reload" nothing happens not even an error in dmesg....the
> reload command has never worked for me no matter what system I use intel
> or amd.
>
> Thanks for helping.
> I can't believe everyone else is so nonchalant about all this
> considering how important it is I still haven't figured out how to
> update the microcode on any of my computers - no guides I have found
> actually work and no distros have the new microcode for intel or amd
> despite it having been months.

I can't believe everybody is so nonchalant about Rowhammer but many
people make a big thing out of the comparatively tiny Spectre problem.
> For the best security one should have both the new microcode and the
> lfence msr?

Not for the best but for any security, you have to understand first that
both options only change something if your software is prepared to uti-
lize them. First update your software, then check what it needs / what
the developers expect (the new microcode I'd guess).

Nico

[awokd]

On Tue, April 24, 2018 11:31 pm, Nico Huber wrote:
> On 25.04.2018 00:18, [e-mail] wrote:
> > I can't believe everyone else is so nonchalant about all this
> > considering how important it is I still haven't figured out how to update
> > the microcode on any of my computers - no guides I have found actually
> > work and no distros have the new microcode for intel or amd despite it
> > having been months.

I'm not nonchalant, but I'm not entirely sure what to do with those patch
files and was hoping to see a new amd microcode 15h bin with them
incorporated.
> I can't believe everybody is so nonchalant about Rowhammer but many
> people make a big thing out of the comparatively tiny Spectre problem.
> > For the best security one should have both the new microcode and the
> > lfence msr?
>
> Not for the best but for any security, you have to understand first that
> both options only change something if your software is prepared to uti-
> lize them. First update your software, then check what it needs / what the
> developers expect (the new microcode I'd guess).

If I remember the earlier discussion right on that lfence msr, the OS can
also set it so although it would be nice if coreboot did as well, it's not
required?

[Ivan Ivanov]

If I understood all this correctly, the updated microcodes should be
forcing the CPU to do these MSR writes (or the low level action which
stands behind them) by default. So that, when you got this updated
microcode on your CPU, its already fixed and no further operations are
necessary!

At the moment both me and Mike have sent many letters to AMD (example
provided below, you could use its parts as well). Have not received
any good reply yet (only one reply, with a stupid link to spectre v2
description page and without any files attached) - but we are trying
hard and hope to eventually reach a smart person at AMD who could help
us...

By the way, these microcodes from platomav github page - are from
february/march, and I believe they do not contain a spectre v2 fix. So
we hope to either eventually get these microcodes from AMD, or to
somehow extract them from a super bloated Win10 update, or to try to
extract them from the updated BIOSes of other companies when they come
out

===
1) go to amd support page and open a ticket form
2) set company as "coreboot" or "coreboot BIOS"
Subject: Updated microcode for coreboot BIOS devs
We, the coreboot BIOS developers, have not received any microcode
updates from AMD (aimed towards patching the spectre v2
vulnerability). AMD sent these updated microcode binaries to many
motherboard and BIOS development companies, but forgot to send these
files to us at coreboot! Could you please provide a standalone
download of your updated microcode binaries, to make it possible for
us to include them to our coreboot BIOS running on AMD platforms ? We
will appreciate if you will share these updated microcode binaries
with us - maybe together with SHA-256 or SHA-512 hashes of these files
or GnuPG signatures to ensure the security of transaction Best
regards, Ivan Ivanov, coreboot BIOS firmware engineer

P.S. Although, ideally these new updated microcodes should be
committed tokernel/git/firmware/linux-firmware.git repository -->
directory called
"amd-ucode" .Currently it contains the following files:
microcode_amd.bin ,microcode_amd.bin.asc , microcode_amd_fam15h.bin
,microcode_amd_fam15h.bin.asc , microcode_amd_fam16h.bin
,microcode_amd_fam16h.bin.asc .They have been last updated at 2015/16
year, and we would like to see them updated again

2018-04-25 4:02 GMT+03:00 awokd via coreboot :
> On Tue, April 24, 2018 11:31 pm, Nico Huber wrote:
> > On 25.04.2018 00:18, [e-mail] wrote:
> > > I can't believe everyone else is so nonchalant about all this
> > > considering how important it is I still haven't figured out how to update
> > > the microcode on any of my computers - no guides I have found actually
> > > work and no distros have the new microcode for intel or amd despite it
> > > having been months.
>
> I'm not nonchalant, but I'm not entirely sure what to do with those patch
> files and was hoping to see a new amd microcode 15h bin with them
> incorporated.
> > I can't believe everybody is so nonchalant about Rowhammer but many
> > people make a big thing out of the comparatively tiny Spectre problem.
> > > For the best security one should have both the new microcode and the
> > > lfence msr?
> >
> > Not for the best but for any security, you have to understand first that
> > both options only change something if your software is prepared to uti-
> > lize them. First update your software, then check what it needs / what the
> > developers expect (the new microcode I'd guess).
>
> If I remember the earlier discussion right on that lfence msr, the OS can
> also set it so although it would be nice if coreboot did as well, it's not
> required?

Re : Re: When does AMD release the fam15 spectre microcode updates?

Hello Rudolf,
First thank your for finding these blobs and the hack to use them, and for testing and validating them.
But please could you tell us what was the setup for your tests :
 - what was your hardware : cpu + mobo (chipset)?
 - what was your linux kernel version?
Thank you beforehand.
Best regards,
 Florentin

----- Mail d'origine -----
De: Rudolf Marek 
À: [e-mail]
Envoyé: Tue, 17 Apr 2018 09:30:57 +0200 (CEST)
Objet: Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

Hi,

I found new microcode here [1], I used cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity family15h CPU.
I hacked together a new microcode header which contains the equivalence table etc to be able to load this microcode into the CPU from Linux.

dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 of=header.bin
cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > microcode_amd_fam15h.bin

copy the file to same location and trigger update:

echo 1 >  /sys/devices/system/cpu/microcode/reload

[ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
[ 6032.964913] microcode: CPU2: new patch_level=0x0600111f

Please note that the header.bin does contain a size of the microcode blob, but it happens to be the same, so it works. Normally the container
may contain more microcode blobs. But in my case I use just "right" one for my CPU.

The new microcode seems to be adding the IBPB feature.

Thanks
Rudolf

[1] https://github.com/platomav/CPUMicrocodes