Page MenuHomeFreeBSD

sysutils/devcpu-data Steal ubuntu's AMD microcode update file.
ClosedPublic

Authored by sbruno on Jan 10 2018, 8:13 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 5, 3:25 PM
Unknown Object (File)
Tue, Mar 5, 3:24 PM
Unknown Object (File)
Tue, Mar 5, 3:24 PM
Unknown Object (File)
Tue, Mar 5, 3:24 PM
Unknown Object (File)
Tue, Mar 5, 3:24 PM
Unknown Object (File)
Mon, Mar 4, 10:41 PM
Unknown Object (File)
Sun, Mar 3, 4:36 AM
Unknown Object (File)
Feb 21 2024, 4:10 AM

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

https://launchpad.net/ubuntu/+source/amd64-microcode/3.20171205.1

Add Family 17h firmware.

I'll stash this in my distfiles sync location for examination for those who are interested.

bdrewery added a subscriber: bdrewery.

Approved for commit and skipping maintainer

This revision is now accepted and ready to land.Jan 10 2018, 8:20 PM

Patch applies cleanly to my ports tree. Builds ok.

$ sudo service microcode_update onestart
Updating CPU Microcode...
Re-evalutation of CPU flags Failed.

Ah, my userspace is old enough that cpucontrol -e does not exist.

Let me update cpucontrol. Do you have a Spectre PoC I can try before and after the microcode patch? Thanks!

cem accepted this revision.EditedJan 10 2018, 10:04 PM

Using spectre PoC here: https://gist.githubusercontent.com/jedisct1/3bbb6e50b768968c30629bf734ea49c6/raw/6ede3c9a3356a4a55a27febaf38157897c4fed09/spectre.c/spectre.c

Before: PoC succeeds.

$ sudo service microcode_update onestart
Updating CPU Microcode...
Done.

After: PoC still succeeds. (This is expected — microcode update just adds IBPB flush intrinsics.)

Can't tell if the re-read of cpu features worked or not, but let's assume it did.

My family 17h AMD system (Zen) is running fine w/ this microcode update, not bricked. Ship it.

Can't tell if the re-read of cpu features worked or not, but let's assume it did.

Is there any way to check the microcode version currently in use?

Is there any way to check the microcode version currently in use?

$ x86info -a | grep Microcode

Unfortunately, it appears the so-called Family 17h microcode update is limited to EPYC (stepping 2) systems, so I haven't tested anything useful.

Examining the amd cpucontrol code has led me to realize that chopping up
the microcode files for AMD cpus is exactly wrong. They are already in
the format that corresponds to our processing via "amd10h" so don't do that
anymore.

This revision now requires review to proceed.Jan 11 2018, 12:49 AM
This revision is now accepted and ready to land.Jan 11 2018, 2:07 AM

I found that "chopping up" the AMD microcode files was incorrect (and probably broken for 3+ years). If you have access to AMD hosts, please try my review on your systems. I now get an update to my FX-8150 with my review.

x86info -a | grep "Microcode patch level"
Microcode patch level: 0x6000629

/var/log/messages:
Jan 10 16:56:52 lab microcode_update: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu /dev/cpuctl0 to revision 0x600063d... done

x86info -a | grep "Microcode patch level"
Microcode patch level: 0x600063d

In D13832#290218, @cem wrote:

Is there any way to check the microcode version currently in use?

$ x86info -a | grep Microcode

Unfortunately, it appears microcode loading is broken on Family 17h, so I haven't tested anything useful.

Should this work for Intel cpu's as well? I have a couple servers that use Intel chips, but I have no idea if the microcode is actually being updated. I suspect it is not, x86info -a doesn't provide any information about the microcode.

In D13832#290218, @cem wrote:

Is there any way to check the microcode version currently in use?

$ x86info -a | grep Microcode

Unfortunately, it appears microcode loading is broken on Family 17h, so I haven't tested anything useful.

Should this work for Intel cpu's as well? I have a couple servers that use Intel chips, but I have no idea if the microcode is actually being updated. I suspect it is not, x86info -a doesn't provide any information about the microcode.

Yes, it should. When I updated the port this week, I ensured that a message would be sent to /var/log/messages if an update actually happens.

Blocking pending update for Intel microcode revert.

Update after Intel microcode revert

This works for my FX-8150:

root@lab:/home/sbruno # x86info -a | grep "CPU Model"
CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2)

root@lab:/home/sbruno # x86info -a | grep Microcode
Microcode patch level: 0x6000629

root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart
Updating CPU Microcode...
Done.

root@lab:/home/sbruno # x86info -a | grep Microcode
Microcode patch level: 0x600063d

root@lab:/home/sbruno # grep microcode_update /var/log/messages
Jan 10 16:52:26 lab microcode_update: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu /dev/cpuctl0 to revision 0x600063d... done.

Hello! I post here because in the forums they say I should report here.

Yesterday I tried microcode update oneshot. It just put out an meaningless message about microcode updated. There was no message in /var/log/messages.

x86info hangs when run as root.
When run as user, it gives incorrect information, stating the processor (X5680) being a 3-core processor with hyperthreading. But, it is a 6core, and hyperthreading is turned off via HP Z800 BIOS (to avoid thrashing).

Did devcpu-data fsck up my cpu?

Hello! I post here because in the forums they say I should report here.

Yesterday I tried microcode update oneshot. It just put out an meaningless message about microcode updated. There was no message in /var/log/messages.

x86info hangs when run as root.
When run as user, it gives incorrect information, stating the processor (X5680) being a 3-core processor with hyperthreading. But, it is a 6core, and hyperthreading is turned off via HP Z800 BIOS (to avoid thrashing).

Did devcpu-data fsck up my cpu?

I believe this is all just an issue with x86info which was updated earlier: https://svnweb.freebsd.org/changeset/ports/458760

Doesn't work here.

cwsys# x86info -a | egrep 'CPU Model|Microcode'
CPU Model (x86info's best guess): Athlon 64 X2 Dual-Core (BH-G2)
cwsys# service microcode_update start
Updating CPU Microcode...
Done.
cwsys# x86info -a | egrep 'CPU Model|Microcode'
CPU Model (x86info's best guess): Athlon 64 X2 Dual-Core (BH-G2)
cwsys# grep microcode_update /var/log/messages
cwsys# cpucontrol -v -u /dev/cpuctl0
cwsys# cpucontrol -v -u /dev/cpuctl1
cwsys#

Possible there may be no microcode update or other issue.

cwsys# x86info -a | grep -i family

APIC ID Version State Family Model Step Flags

Extended Family: 0 Extended Model: 6 Family: 15 Model: 107 Stepping: 2
cwsys#

Same result using prior version of port.

Looks like my issue is outside of the scope of this review. All firmwares result in same as the following:

cpucontrol: found cpu family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6.
cpucontrol: /usr/local/share/cpucontrol/m01f2529.fw is not a valid amd firmware: version mismatch

Might be a good idea at some point to have cpucontrol list the family, model and step of each firmware to allow for verification and debugging.

Adding:

cpucontrol: found cpu family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6.
cpucontrol: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin is not a valid amd firmware: version mismatch

Using the old unmodified port with split AMD firmwares:

cpucontrol: /tmp/cpucontrol/AMD-00007001-0700010f.fw: update data checksum invalid
cpucontrol: /tmp/cpucontrol/AMD-00006101-06001119.fw is not a valid amd firmware: version mismatch
cpucontrol: /tmp/cpucontrol/AMD-00006012-0600063d.fw is not a valid amd firmware: version mismatch
cpucontrol: /tmp/cpucontrol/AMD-00005010-05000029.fw: update data checksum invalid
cpucontrol: /tmp/cpucontrol/AMD-00005020-05000119.fw: update data checksum invalid
cpucontrol: /tmp/cpucontrol/AMD-00006020-06000832.fw is not a valid amd firmware: version mismatch

In D13832#290895, @cy wrote:

Using the old unmodified port with split AMD firmwares:

The split firmwares are a red herring, I think. Ignore those.

Adding:

cpucontrol: found cpu family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6.
cpucontrol: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin is not a valid amd firmware: version mismatch

Try this cpucontrol patch (warning, it's spammy):

--- amd10h.c    (revision 327859)
+++ amd10h.c    (working copy)
@@ -77,6 +77,7 @@
        }
        signature = idargs.data[0];
        family = ((signature >> 8) & 0x0f) + ((signature >> 20) & 0xff);
+       fprintf(stderr, "%s: family: 0x%x\n", __func__, family);
        if (family < 0x10)
                return (1);
        return (0);
@@ -128,6 +129,7 @@
                goto done;
        }
        signature = idargs.data[0];
+       fprintf(stderr, "%s: signature: 0x%x\n", __func__, signature);

        msrargs.msr = 0x0000008b;
        error = ioctl(devfd, CPUCTL_RDMSR, &msrargs);
@@ -213,6 +215,7 @@

        equiv_id = 0;
        for (i = 0; equiv_cpu_table[i].installed_cpu != 0; i++) {
+               fprintf(stderr, "%s: installed_cpu: 0x%x\n", __func__, equiv_cpu_table[i].installed_cpu);
                if (signature == equiv_cpu_table[i].installed_cpu) {
                        equiv_id = equiv_cpu_table[i].equiv_cpu;
                        WARNX(3, "equiv_id: %x", equiv_id);
@@ -220,7 +223,7 @@
                }
        }
        if (equiv_id == 0) {
-               WARNX(2, "CPU is not found in the equivalence table");
+               WARNX(2, "%s: CPU is not found in the equivalence table", path);
                goto done;
        }

With the unsplit microcodes, I see:

$ cpucontrol -vvv -u  /dev/cpuctl0
...
amd10h_update: signature: 0x800f11          // my CPUID
cpucontrol: found cpu family 0xf model 0x1 stepping 0x1 extfamily 0x8 extmodel 0.
cpucontrol: microcode revision 0x8001129
...
amd10h_update: installed_cpu: 0x800f12        // supported CPUID from 17h firmware
cpucontrol: /usr/local/share/cpucontrol/microcode_amd_fam17h.bin: CPU is not found in the equivalence table
...
amd10h_update: installed_cpu: 0x600f20        // supported CPUID from 15h firmware
amd10h_update: installed_cpu: 0x610f01
amd10h_update: installed_cpu: 0x600f12
cpucontrol: /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: CPU is not found in the equivalence table
...
amd10h_update: installed_cpu: 0x700f01        // supported CPUID from 16h firmware
cpucontrol: /usr/local/share/cpucontrol/microcode_amd_fam16h.bin: CPU is not found in the equivalence table

Your CPU, "family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6" should be 0x60fb2 -- which, yeah, isn't one of 0x600f20, 0x610f01, or 0x600f12. So this microcode file doesn't have an update for your CPU, as I understand it.

I've come to that conclusion too. My three machines are two low power (65w) winsor (family 15h, model 107, stepping 2) and one 89w winsor (family 15h, model 75, stepping 2).

Additionally, x86info returns a val of zero from read_msr() when reading microcode version.

The port works perfectly on my laptop (i3-2350M).

In D13832#290897, @cem wrote:

Your CPU, "family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6" should be 0x60fb2 -- which, yeah, isn't one of 0x600f20, 0x610f01, or 0x600f12. So this microcode file doesn't have an update for your CPU, as I understand it.

I am not sure whether you are correct in this assumption.
The name mangling that is done by ucode-tool is bad and confusing. Imho ucode-tool should be retired, as it is legacy stuff, and the vendor-supplied binary files be used instead for more consistency.
I have done a write-up about this topic on the FreeBSD forums here, where I analyze why the microcode_update thing seems to be broken due to a fundamentally wrong approach.

In D13832#290897, @cem wrote:

Your CPU, "family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6" should be 0x60fb2 -- which, yeah, isn't one of 0x600f20, 0x610f01, or 0x600f12. So this microcode file doesn't have an update for your CPU, as I understand it.

I am not sure whether you are correct in this assumption.
The name mangling that is done by ucode-tool is bad and confusing. Imho ucode-tool should be retired, as it is legacy stuff, and the vendor-supplied binary files be used instead for more consistency.
I have done a write-up about this topic on the FreeBSD forums here, where I analyze why the microcode_update thing seems to be broken due to a fundamentally wrong approach.

The CPU under discussion is an AMD model and the firmware files under discussion are "unsplit" directly from the vendor. So I don't think your comment on the forum applies *in this case*. It may well be that we can do better for Intel µcode updates.

In D13832#290897, @cem wrote:

Your CPU, "family 0xf model 0xb stepping 0x2 extfamily 0 extmodel 0x6" should be 0x60fb2 -- which, yeah, isn't one of 0x600f20, 0x610f01, or 0x600f12. So this microcode file doesn't have an update for your CPU, as I understand it.

I am not sure whether you are correct in this assumption.
The name mangling that is done by ucode-tool is bad and confusing. Imho ucode-tool should be retired, as it is legacy stuff, and the vendor-supplied binary files be used instead for more consistency.
I have done a write-up about this topic on the FreeBSD forums here, where I analyze why the microcode_update thing seems to be broken due to a fundamentally wrong approach.

Based on your feedback. I went ahead and tested to see if we can just use the microcode files (instead of chopping up the microcode.dat file) as our source of updates. It sure looks like it works and would match what we all can see that linux does. I moved all of the "chopped up" Intel files out of the way and installed the much simpler XX-XX-XX files. My test machines see them as valid microcode files, detect a needed rev update and do the needful.

cpucontrol -vvv -u /dev/cpuctl0
...
cpucontrol: found cpu type 0 family 0x6 model 0xc stepping 0x3.
/usr/local/share/cpucontrol/06-3c-03: updating cpu /dev/cpuctl0 from rev 0x17 to rev 0x22... done.
cpucontrol: found cpu type 0 family 0x6 model 0xc stepping 0x3.
...

Successive runs against the came cpu node fail correctly noting that the update is complete:

cpucontrol -vvv -u /dev/cpuctl0
...
cpucontrol: found cpu type 0 family 0x6 model 0xc stepping 0x3.
cpucontrol: skipping /usr/local/share/cpucontrol/06-3c-03 of rev 0x22: up to date
cpucontrol: found cpu type 0 family 0x6 model 0xc stepping 0x3.
...

This is beyond the scope for this update, but I'm going to move forward with a seperate review and drop the ucode chopping/breakup for future releases.

This revision was not accepted when it landed; it landed in state Needs Review.Jan 13 2018, 9:36 PM
This revision was automatically updated to reflect the committed changes.