Project

General

Profile

Feature #39099

Let the CPU microcode update when applicable

Added by Alexander Motin about 1 year ago. Updated 6 months ago.

Status:
Done
Priority:
Important
Assignee:
Sean Fagan
Category:
Hardware
Target version:
Estimated time:
Severity:
Med High
Reason for Closing:
Reason for Blocked:
Needs QA:
No
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Description

The sysutils/devcpu-data port can update Intel microcode.

Should the rc.conf entry be enabled by default? (microcode_update_enable="YES")


Related issues

Copied from FreeNAS - Feature #27820: Add sysutils/devcpu-dataDone

Associated revisions

Revision 52194d1b (diff)
Added by Sean Fagan 7 months ago

Let the microcode update, if applicable. Ticket: #39099

History

#1 Updated by Alexander Motin about 1 year ago

#2 Updated by Alexander Motin about 1 year ago

  • Status changed from Unscreened to Not Started

#3 Updated by Alexander Motin 7 months ago

  • Status changed from Not Started to Unscreened
  • Assignee changed from Alexander Motin to Sean Fagan

Sean, could you investigate this in respect whether it can harm, for example, by downgrading newer microcode if one we ship is older at some point. If nothing, lets enable it and see what explode.

#4 Updated by Sean Fagan 7 months ago

  • Status changed from Unscreened to Screened

Updating the microcode is a problem — it means we depend on updating the port as often as there are microcode updates, and then we have to depend on the vendor entirely, because we have no ability to audit what the changes are.

That said, I’ve been running two servers with it enabled for 6 months now, and haven’t had any noticeable problems. But then, the other two servers don't have it enabled, and I also haven't really noticed anything with them.

This is more of an managerial call than technical -- should we do this, given the constraints?

#5 Updated by Alexander Motin 7 months ago

Sean Fagan wrote:

we depend on updating the port as often as there are microcode updates

If the microcode loading code can not downgrade what is provide by motherboard, then I think it is not so big problem.

and then we have to depend on the vendor entirely, because we have no ability to audit what the changes are.

I think this is just how the industry work already. We already trust it when we are receiving new BIOS image.

That said, I’ve been running two servers with it enabled for 6 months now, and haven’t had any noticeable problems. But then, the other two servers don't have it enabled, and I also haven't really noticed anything with them.

I'd be really surprised if you noticed anything without close investigations.

This is more of an managerial call than technical -- should we do this, given the constraints?

It was so many times told that we should, that postponing it longer is not serious. :)

#6 Updated by Sean Fagan 7 months ago

  • Status changed from Screened to In Progress

heh

It checks the firmware version on the CPU against a matching firmware file, and doesn't apply it if the version is newer. Specifically:

        if (revision >= fw_header->revision) {
                WARNX(1, "skipping %s of rev %#x: up to date",
                    path, fw_header->revision);
                goto fail;
        }

So this would mean two things:
  1. Adding devcpu-data to the port list
  2. Adding microcode_update_enable="YES" to the rc.conf file(s).

#7 Updated by Alexander Motin 7 months ago

It is already in the port list, but we never really tested it.

#8 Updated by Sean Fagan 7 months ago

I've tested it on a couple of physical systems (a small intel nuc, and a freenas mini), and a VMWare VM. Pull request 2556 for freenas/freenas.

However: this may be something we want to make a configurable option. In which case it'll need middleware changes, which are out of my comfort zone.

#9 Updated by Sean Fagan 7 months ago

  • Status changed from In Progress to Ready for Testing

#10 Updated by Alexander Motin 7 months ago

There is a way to set rc.conf variables in UI, if needed. Hope it should be able to override defaults.

I see the PR, but it was not pushed to set "Ready for testing". :)

#11 Updated by Bug Clerk 7 months ago

#12 Updated by Dru Lavigne 7 months ago

  • Subject changed from Test and enable CPU microcode update to Let the CPU microcode update when applicable
  • Target version changed from 11.3 to 11.3-BETA1
  • Needs Merging changed from Yes to No

#13 Updated by Sean Fagan 6 months ago

I do not think there is a specific way to test this -- while some of the microcode patches may have testable material, the vendors are pretty tight-lipped about it.

#14 Updated by Dru Lavigne 6 months ago

  • Status changed from Ready for Testing to Done
  • Needs QA changed from Yes to No
  • Needs Doc changed from Yes to No

#15 Updated by Dru Lavigne 6 months ago

  • Target version changed from 11.3-BETA1 to 11.3-ALPHA1

Also available in: Atom PDF