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.
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
http://www.amd64.org/microcode/amd-ucode-2014-12-01.tar.bz2 is unreachable.
(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
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
@grarpamp: could you submit a new patch for AMD microcode? Thanks!
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.
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
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.
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?
(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.
(In reply to grarpamp from comment #0) Intel released a new version to commit... https://downloadcenter.intel.com/download/26925/Linux-Processor-Microcode-Data-File https://downloadmirror.intel.com/26925/eng/microcode-20170707.tgz Searching sometimes provides some hints for each release... https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/common/recipes-core/microcode https://github.com/LibreELEC/LibreELEC.tv/commit/b491ada668c5895307eda63c7a7f2e212d32466b
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
Sorry, didn't see this one until after I committed bug 221246. If there's anything here to do, please re-open.
(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