Bug 219268

Summary: sysutils/devcpu-data New Microcode Released for Intel / AMD
Product: Ports & Packages Reporter: grarpamp
Component: Individual Port(s)Assignee: Po-Chuan Hsieh <sunpoet>
Status: Closed Overcome By Events    
Severity: Affects Many People CC: clarkjc, freebsd, swills, vvd
Priority: --- Flags: clarkjc: maintainer-feedback+
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
sysutils/devcpu-data: Update Intel microcode to 2017-05-11
clarkjc: maintainer-approval+
AMD microcode from kernel.org none

Description grarpamp 2017-05-13 23:31:43 UTC
https://downloadcenter.intel.com/download/26798/Linux-Processor-Microcode-Data-File
https://downloadmirror.intel.com/26798/eng/microcode-20170511.tgz

And the :intel master_site needs updated to use https.

Timing may be related to intel-sa-00075.
Comment 1 John Clark 2017-05-24 21:26:19 UTC
Created attachment 182872 [details]
sysutils/devcpu-data: Update Intel microcode to 2017-05-11

* Update Intel microcode to 2017-05-11
* Use HTTPS for Intel master site
Comment 2 Po-Chuan Hsieh freebsd_committer freebsd_triage 2017-05-27 09:21:29 UTC
http://www.amd64.org/microcode/amd-ucode-2014-12-01.tar.bz2 is unreachable.
Comment 3 grarpamp 2017-05-28 21:28:47 UTC
(In reply to Po-Chuan Hsieh from comment #2)
Right. And the AMD microcode set has also been updated over
a year ago to fix critical reproducible crash and exploit.
Download the latest from gko below, verify the signatures, bundle
it all into a tarball named amd_ucode-20160316_0x0600084f.txz, push it
out to distfiles, and point the Makefile at it, referencing the new sha256.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amd-ucode

Another update to this port will be required to fix user exploitable
lockup on AMD Zen Ryzen CVE-2017-7262. You might need to extract microcode
from good board vendors BIOS releases in order to apply to CPUs on other
board vendors that refuse to provide updates to their onboard blobs.

Of course loading microcode as early as possible is best,
ref example: AW67 on pg 42. It might be possible for a kernel
module or option to load microcode earlier than userland.
http://download.intel.com/design/processor/specupdt/318733.pdf
Comment 4 commit-hook freebsd_committer freebsd_triage 2017-05-29 15:30:08 UTC
A commit references this bug:

Author: sunpoet
Date: Mon May 29 15:28:47 UTC 2017
New revision: 442023
URL: https://svnweb.freebsd.org/changeset/ports/442023

Log:
  Update Intel microcode to 2017-05-11

  - Update MASTER_SITES: use https:// for Intel
  - While I'm here, add NO_ARCH

  PR:		219268
  Submitted by:	grarpamp <grarpamp@gmail.com>
  Approved by:	John Clark <clarkjc@runbox.com> (maintainer)

Changes:
  head/sysutils/devcpu-data/Makefile
  head/sysutils/devcpu-data/distinfo
  head/sysutils/devcpu-data/pkg-plist
Comment 5 Po-Chuan Hsieh freebsd_committer freebsd_triage 2017-05-29 15:44:51 UTC
@grarpamp: could you submit a new patch for AMD microcode? Thanks!
Comment 6 grarpamp 2017-06-01 08:37:37 UTC
Created attachment 183119 [details]
AMD microcode from kernel.org

AMD canonical site is unknown / down, and the port auto assembling from kernel.org would be too fragile... so this file will need pushed out to:
https://distcache.freebsd.org/ports-distfiles/amd-ucode-20160316.txz
SHA256 (amd-ucode-20160316.txz) = b1e7d27deff4ecb5f9f0005a274d8c59470858e63838285dbadf20b47a17b6b0
The sigs verify with keys from SKS, md5s in upstream kernel.org commit msgs match, date in filename (aka: "version") taken from said msgs, files timestamped to respective commit dates.

Patch is still open for whoever.
Comment 7 grarpamp 2017-06-09 06:30:12 UTC
Intel / AMD may engage in pruning of older CPUs from current releases. Adding this as one potential microcode source for older computers, particularly AMD (Intel still publishes back to 2009. Both could be collected and collated into this port for posterity).
https://review.coreboot.org/cgit/blobs.git/tree/cpu
Comment 8 Alexey Koscheev 2017-06-26 11:48:01 UTC
FreeBSD 11.0-RELEASE-p8.

pkg info -E devcpu-data
devcpu-data-1.10

From /var/run/dmesg.boot
CPU: Intel(R) Xeon(R) CPU E3-1240 v5 @ 3.50GHz (3504.17-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3

service microcode_update onestart
Updating cpucodes...
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl0 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl0 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl1 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl1 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl2 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl2 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl3 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl3 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl4 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl4 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl5 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl5 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl6 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl6 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl7 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
/usr/local/share/cpucontrol/m36506e3_000000b9_000000ba.fw: updating cpu /dev/cpuctl7 from rev 0x6a to rev 0xba... failed.
cpucontrol: ioctl(): Invalid argument
Done.
Comment 9 Vladimir Druzenko freebsd_committer freebsd_triage 2017-07-01 23:07:29 UTC
Intel dropped support of the Pentium 3/4 and old Xeons in 2015 from firmware distribution.
The last version with support of old CPUs is https://downloadmirror.intel.com/24661/eng/microcode-20150121.tgz

Can you add it in this port or as separate port?
Comment 10 grarpamp 2017-07-02 05:23:53 UTC
(In reply to vvd from comment #9)
Assuming it wasn't to drop a buggy ucode rev (Attention vendors, please document your releases!), failing to simply carry / dist them is poor support, people still use P55C's and K6's.

The makefile handles both AMD and Intel already.
Afaik, all microcodes for both are internally checksummed / signed, versioned, and can be uprev'd into the cpu. Some testing may be warranted there.
Gather all the historical bundles by AMD / Intel separately, find and use the ucode splitters to break them into individual files, and tarball them out to distfiles, one big bundle each for AMD and Intel. If being paranoid / pedantic of undocumented bugs / support status, the backhistory could be punted to a new devcpu-data-legacy port... seems pointless though.

To get the latest ucodes out to users sooner, I'd commit the current tarballs, then go back and commit the backhistory. Users can drop old blobs into the fw dir till then.
Comment 12 grarpamp 2017-08-03 06:01:02 UTC
This work has already produced lockup from userland. It and future work is likely to bring more AMD/Intel updates to commit.
https://raw.githubusercontent.com/xoreaxeaxeax/sandsifter/master/references/domas_breaking_the_x86_isa_wp.pdf
Comment 13 Steve Wills freebsd_committer freebsd_triage 2017-09-17 18:14:12 UTC
Sorry, didn't see this one until after I committed bug 221246. If there's anything here to do, please re-open.
Comment 14 Vladimir Druzenko freebsd_committer freebsd_triage 2017-09-17 20:51:27 UTC
(In reply to Steve Wills from comment #13)
Can you add support for older Intel CPUs?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219268#c9