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!
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...
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
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...
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
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?
On 25.04.2018 00:18, Taiidan@gmx.com 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
On Tue, April 24, 2018 11:31 pm, Nico Huber wrote:
On 25.04.2018 00:18, Taiidan@gmx.com 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?
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 <coreboot@coreboot.org>:
On Tue, April 24, 2018 11:31 pm, Nico Huber wrote:
On 25.04.2018 00:18, Taiidan@gmx.com 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?
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
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 <r.marek@assembler.cz> À: coreboot@coreboot.org 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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
participants (6)
-
awokd -
echelon＠free.fr -
Ivan Ivanov -
Nico Huber -
Rudolf Marek -
Taiidan＠gmx.com