--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: jessie-pu: package intel-microcode/3.20151106.1~deb8u1
- From: Henrique de Moraes Holschuh <hmh@debian.org>
- Date: Mon, 28 Dec 2015 17:12:34 -0200
- Message-id: <20151228191234.GA10333@khazad-dum.debian.net>
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian.org@packages.debian.org
Usertags: pu
I would like to update the intel-microcode package in Debian stable
(jessie), to the microcode that is already being shipped in unstable since
2015-11-10, in testing since 2015-11-15, and in jessie-backports since
2015-11-28.
In fact, I'd like to update Debian stable to the same package that is
already in unstable/testing *and* in jessie-backports, with changes only to
the version numbering (and related changelog entry).
This update fixes several critical Intel processor errata on widely used
Intel processors (Haswell and Broadwell, as well as their related Xeons).
Without this microcode update, Intel Broadwell systems [running outdated
firmware] have a very high chance of crashing or locking up. It fixes a
number of nasty issues on Intel Haswell Refresh and Intel Haswell processors
as well.
Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=103351 for a
comprehensive crash report that is fixed by this microcode update.
The debdiff is a bit bigger than usual because I kept all the changes from
the intel-microcode package in unstable / testing / jessie-backports. These
changes cover documentation updates, and also an improved Makefile to allow
for a safer (against human error) way to add "emergency" microcode updates,
which are likely to be needed soon.
The Makefile changes only affect the build, and they have been extensively
tested.
As usual, you will find attached the debdiff output with the changes in the
two microcode data files removed for brevity...
Diffstat below:
Makefile | 119
changelog | 12
debian/README.source | 190
debian/changelog | 44
debian/control | 2
debian/rules | 6
debian/ucode-blacklist.txt | 5
microcode-20150121.dat |41591 -------------------------------------------
microcode-20151106.dat |43449 +++++++++++++++++++++++++++++++++++++++++++++
9 files changed, 43726 insertions(+), 41692 deletions(-)
(diffstat of the abridged debdiff, for better resolution):
Makefile | 119 +++++++++++++++++++---------
changelog | 12 ++
debian/README.source | 190 ++++++++++++++++++++++++++++++---------------
debian/changelog | 44 ++++++++++
debian/control | 2
debian/rules | 6 -
debian/ucode-blacklist.txt | 5 +
7 files changed, 277 insertions(+), 101 deletions(-)
Thank you!
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
diff -Nru intel-microcode-3.20150121.1/changelog intel-microcode-3.20151106.1~deb8u1/changelog
--- intel-microcode-3.20150121.1/changelog 2015-01-29 20:57:13.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/changelog 2015-12-28 11:54:52.000000000 -0200
@@ -1,3 +1,15 @@
+2015-11-06:
+ * New Microcodes:
+ sig 0x000306f4, pf mask 0x80, 2015-07-17, rev 0x0009, size 14336
+ sig 0x00040671, pf mask 0x22, 2015-08-03, rev 0x0013, size 11264
+
+ * Updated Microcodes:
+ sig 0x000306a9, pf mask 0x12, 2015-02-26, rev 0x001c, size 12288
+ sig 0x000306c3, pf mask 0x32, 2015-08-13, rev 0x001e, size 21504
+ sig 0x000306d4, pf mask 0xc0, 2015-09-11, rev 0x0022, size 16384
+ sig 0x000306f2, pf mask 0x6f, 2015-08-10, rev 0x0036, size 30720
+ sig 0x00040651, pf mask 0x72, 2015-08-13, rev 0x001d, size 20480
+
2015-01-21:
* Downgraded microcodes (to a previously shipped revision):
sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672
diff -Nru intel-microcode-3.20150121.1/debian/changelog intel-microcode-3.20151106.1~deb8u1/debian/changelog
--- intel-microcode-3.20150121.1/debian/changelog 2015-01-29 20:57:19.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/debian/changelog 2015-12-28 16:06:24.000000000 -0200
@@ -1,3 +1,47 @@
+intel-microcode (3.20151106.1~deb8u1) stable; urgency=medium
+
+ * Rebuild for jessie (stable update), no changes required
+ * This is the same package as 3.20151106.1~bpo8+1 (jessie-backports)
+ and 3.20151106.1 (unstable, stretch)
+
+ -- Henrique de Moraes Holschuh <hmh@debian.org> Mon, 28 Dec 2015 15:57:14 -0200
+
+intel-microcode (3.20151106.1) unstable; urgency=medium
+
+ * New upstream microcode data file 20151106
+ + New Microcodes:
+ sig 0x000306f4, pf mask 0x80, 2015-07-17, rev 0x0009, size 14336
+ sig 0x00040671, pf mask 0x22, 2015-08-03, rev 0x0013, size 11264
+ + Updated Microcodes:
+ sig 0x000306a9, pf mask 0x12, 2015-02-26, rev 0x001c, size 12288
+ sig 0x000306c3, pf mask 0x32, 2015-08-13, rev 0x001e, size 21504
+ sig 0x000306d4, pf mask 0xc0, 2015-09-11, rev 0x0022, size 16384
+ sig 0x000306f2, pf mask 0x6f, 2015-08-10, rev 0x0036, size 30720
+ sig 0x00040651, pf mask 0x72, 2015-08-13, rev 0x001d, size 20480
+ * This massive Haswell + Broadwell (and related Xeons) update fixes
+ several critical errata, including the high-hitting BDD86/BDM101/
+ HSM153(?) which triggers an MCE and locks the processor core
+ (LP: #1509764)
+ * Might fix critical errata BDD51, BDM53 (TSX-related)
+ * source: remove superseded upstream data file: 20150121
+ * Add support for supplementary microcode bundles:
+ + README.source: update and mention supplementary microcode
+ + Makefile: support supplementary microcode
+ Add support for supplementary microcode bundles, which (unlike .fw
+ microcode override files) can be superseded by a higher revision
+ microcode from the latest regular microcode bundle. Also, fix the
+ "oldies" target to have its own exclude filter (IUC_OLDIES_EXCLUDE)
+ * Add support for x32 arch:
+ + README.source: mention x32
+ + control,rules: enable building on x32 arch (Closes: #777356)
+ * ucode-blacklist: add Broadwell and Haswell-E signatures
+ Add a missing signature for Haswell Refresh (Haswell-E) to the "must
+ be updated only by the early microcode update driver" list. There is
+ at least one report of one of the Broadwell microcode updates disabling
+ TSX-NI, so add them as well just in case
+
+ -- Henrique de Moraes Holschuh <hmh@debian.org> Mon, 09 Nov 2015 23:07:32 -0200
+
intel-microcode (3.20150121.1) unstable; urgency=critical
* New upstream microcode data file 20150121
diff -Nru intel-microcode-3.20150121.1/debian/control intel-microcode-3.20151106.1~deb8u1/debian/control
--- intel-microcode-3.20150121.1/debian/control 2015-01-29 20:57:13.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/debian/control 2015-12-28 15:57:04.000000000 -0200
@@ -11,7 +11,7 @@
XS-Autobuild: yes
Package: intel-microcode
-Architecture: i386 amd64
+Architecture: i386 amd64 x32
Depends: ${misc:Depends}, iucode-tool (>= 1.0)
Recommends: initramfs-tools (>= 0.113~)
Conflicts: microcode.ctl (<< 0.18~0)
diff -Nru intel-microcode-3.20150121.1/debian/README.source intel-microcode-3.20151106.1~deb8u1/debian/README.source
--- intel-microcode-3.20150121.1/debian/README.source 2015-01-29 20:57:13.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/debian/README.source 2015-12-28 15:57:04.000000000 -0200
@@ -3,38 +3,96 @@
Adding new microcodes to the package:
-* Microcode bundles:
- - Add it to the toplevel dir, names must match the patterns:
- - microcode-<id>.dat for Intel text format bundles
- - microcode-<id>.bin for Intel binary bundles
-
- - <id> should be the upstream release date. If it is not,
- you must make sure microcode files that have been released
- later also come later in C collating order.
-
-* Individual microcodes (at a specific revision):
- - highest precedence, will override the ones in the bundles
- - must be in binary format
- - "iucode_tool -s <signature> -W" can be used to easily extract
- microcodes and create .fw override files
- - Add it to the toplevel dir, names should be in the format:
- s<sig>_m<pfmask>_r<revision>.fw
-
- Where <sig> is the CPU signature, <pfmask> is the processor
- flags mask, and revision is the microcode revision level.
- All values in hexadecimal using uppercase letters, no
- leading prefixes, with left padding with zeroes, field
- length 8, as in the printf mask: s%08X_m%08X_r%08X.fw
+* Regular microcode bundles:
+
+ Add them to the top-level dir, names must match the patterns:
+
+ * microcode-<id>.dat for Intel text format bundles;
+ * microcode-<id>.bin for Intel binary bundles.
+
+ <id> should be the upstream release date in YYYYMMDD format.
+ If it is not, you must make sure microcode files that have
+ been released later also come later in C collating order.
+
+ Later regular microcode bundles have precedence over older regular
+ microcode bundles, and may downgrade microcode revisions. This
+ implements the automatic "revision rollback" mechanism.
+
+ The "oldies" and the IUC_INCLUDE mechanisms of the main Makefile may
+ select microcodes from any of the regular microcode bundles.
+ Otherwise, only microcodes in the latest regular microcode bundle will
+ be selected. This logic implements the "automatic removal" mechanism
+ to handle microcode recalls.
+
+ Supplementary microcode bundles and microcode overrides can select
+ additional microcode.
* Latest available version of a microcode that is not being shipped
anymore, but which is present in an older microcode bundle:
- - Add "-s <signature>" to IUC_INCLUDE in the Makefile
-These rules ensure proper sorting, as loading order is important. Bundles
-that sort later are allowed to downgrade microcode supplied by bundles
-that sort earlier. Excluded microcodes (IUC_EXCLUDE in the Makefile) have
-the highest priority and will always be removed from the final set of
-microcodes.
+ Add "-s <signature>" to IUC_INCLUDE in the Makefile.
+
+* Supplementary microcode bundles:
+
+ The intended usage for this feature is to ship microcode updates that
+ fix important errata before they are available through a regular Intel
+ microcode bundle release.
+
+ Add them to the top-level dir, names must match the pattern:
+
+ * supplementary-ucode-<id>.bin
+
+ <id> should be a descriptive name, sorting order does not
+ matter. It must not have spaces or tabs.
+
+ These bundles have the same precedence as the newest regular microcode
+ bundle: microcodes with the highest revision among the newest regular
+ microcode bundle and every supplementary microcode bundles will be
+ selected
+
+ Supplementary microcode bundles must be in binary format.
+
+ Use "iucode_tool -w" to create supplementary microcode bundles. The
+ bundles may have any number of microcodes inside, and should be
+ described in the "upstream" changelog.
+
+ WARNING: by definition, microcodes added through supplementary bundles
+ cannot be "recalled" (excluded or downgraded) automatically by the
+ latest regular microcode bundle, only by overrides and IUC_EXCLUDE.
+
+* Individual microcode overrides (at a specific revision):
+
+ The intended usage for this feature is to ship microcode at a specific
+ revision. For microcode that should be superseded by a newer version
+ when available, use a supplementary bundle (see above), instead.
+
+ These overrides have the highest precedence, and will override
+ (possibly downgrading) microcodes in the other bundles, regular or
+ supplementary.
+
+ Add them to the top-level dir, names should be in the format:
+
+ * s<sig>_m<pfmask>_r<revision>.fw
+
+ <sig> is the CPU signature, <pfmask> is the processor flags
+ mask, and revision is the microcode revision level. All
+ values in hexadecimal using uppercase letters, no leading
+ prefixes, with left padding with zeroes, field length 8, as
+ in the printf mask: s%08X_m%08X_r%08X.fw
+
+ The files must be in binary format, and should contain only a single
+ microcode (to ensure maintainer sanity).
+
+ "iucode_tool -s <signature> -W" can be used to easily extract
+ microcodes and create (and name) .fw override files.
+
+* Excluding microcodes, no matter where they were sourced from:
+
+ Add "-s <signature>" to IUC_EXCLUDE in the Makefile.
+
+ This will remove from the final microcode distribution even microcodes
+ that were sourced from override files.
+
When you add a new microcode (bundle or otherwise):
@@ -46,68 +104,76 @@
Please avoid shipping microcodes "recalled" by Intel, unless you DO know
better (i.e. you know the reason why it was "recalled", and you consider
-that Debian users would be best served by its inclusion). Always document
-why you're doing this as much as you are allowed to in the package
-changelog. Microcode override files (.fw files) can be used to make sure
-a specific microcode is shipped, however, should you want to ship the
-latest available version of a microcode from older bundles, you must use
-IUC_INCLUDE.
+that Debian users would be best served by its inclusion). Always
+document why you're doing this as much as you are allowed to in the
+package changelog. Microcode override files (.fw files) can be used to
+make sure a specific microcode is shipped, however, should you want to
+ship the latest available version of a microcode from older bundles, you
+must use IUC_INCLUDE.
If you are adding a microcode bundle made available directly by Intel in
their public site, please update the "upstream changelog". There is no
-fully automated way to do it yet, but you can use "iucode_tool -l" to list
-the contents of the bundles, and apply some sed magic, sort, and "diff -u"
-to find out which microcodes were added, deleted, updated, or downgraded.
-The debian/diff-latest-pack.sh script should be of help.
+fully automated way to do it yet, but you can use "iucode_tool -l" to
+list the contents of the bundles, and apply some sed magic, sort, and
+"diff -u" to find out which microcodes were added, deleted, updated, or
+downgraded. The debian/diff-latest-pack.sh script should be of help.
Please check all additions against the changelog, and annotate them as
appropriate when the microcode was present in a previous release. Intel
-has done a "delete in one release, add back with a downgraded revision in
-the next release" once in the past. Annotations should say when the
-microcode was updated or downgraded, or just readded with the same
+has done a "delete in one release, add back with a downgraded revision
+in the next release" once in the past. Annotations should say when the
+microcode was updated or downgraded, or just re-added with the same
revision.
Please check all deletions. When very recent microcode is deleted, it
could well mean an unfriendly "microcode revision recall" is happening
(someone at Intel decided to remove it instead of directly marking it a
downgrade by publishing the previously known-good revision). When
-microcodes for older processors are deleted, it is probably safe to assume
-it is just the regular housekeeping cleanups, and the microcode should
-still be shipped by distros that have users running 10-15 year-old boxes,
-like Debian.
+microcodes for older processors are deleted, it is probably safe to
+assume it is just the regular housekeeping cleanups, and the microcode
+should still be shipped by distros that have users running 10-15
+year-old boxes, like Debian.
If you know that a microcode signature belongs to alpha or beta hardware
-(engineering samples), remove the microcodes for that signature by adding
-them to IUC_EXCLUDE in the Makefile. Such microcodes just waste space on
-everyone's system. Unfortunately, a list of the cpu signatures of such
-unsupported processors is hard to come by.
+(engineering samples), you may remove the microcodes for that signature
+by adding them to IUC_EXCLUDE in the Makefile, on the grounds that such
+microcodes just waste space on everyone's system. Unfortunately, a list
+of the CPU signatures of such unsupported processors is hard to come by.
-Keeping useless microcode out of amd64 binary packages:
+Keeping useless microcode out of amd64 and x32 binary packages:
It is useless to ship microcode that targets processors not capable of
-Intel64 (X86-64) on the amd64 arch-specific binary package.
+Intel64 (X86-64) on the amd64 and x32 arch-specific binary packages.
-The toplevel Makefie tries to avoid this by parsing cpu-signatures.txt and
-ignoring anything listed as i?86 when building intel-microcode-64.bin,
+The top-level Makefile tries to avoid this by parsing cpu-signatures.txt
+and ignoring anything listed as i?86 when building intel-microcode-64.bin,
which debian/rules will use instead of intel-microcode.bin for non-i386.
Failure to update cpu-signatures.txt should be mostly harmless (it is
-engineered to fail safe, and distribute unlisted microcode so that at most
-it will waste some space). It is unlikely that new i686 microcode
-signatures will show up, but it may be useful to know to which processors a
-microcode update apply even for newer processors, just in case we have to
-issue a critical update and warn users.
+engineered to fail safe, and distribute unlisted microcode so that at
+most it will waste some space). It is unlikely that new i686 microcode
+signatures will show up, but it may be useful to know to which
+processors a microcode update apply even for newer processors, just in
+case we have to issue a critical update and warn users.
Where to find processor signature information:
They appear to be listed only in the Specification Updates for each
processor, you'll have to locate and download them all from Intel's site
-(this is _not_ easy to do, some of these documents are hard to track down).
-There is a CPUID database in the Internet which may help. Cross-check by
-searching the S-SPEC numbers in the Intel ARK directory (e.g. to verify
-whether it supports X86-64 or not).
+(this is _not_ easy to do, some of these documents are hard to track
+down). Better information is likely to available (possibly under NDA)
+on the Intel developer channels.
+
+As for non-canonical sources, there is a CPUID database in the Internet
+and a memory/latency timings database used by HPC people which are of
+some help. Search engines will often find a BIOS/UEFI firmware upgrade
+changelog that names the particular core of a microcode update
+signature.
+
+Cross-check by searching the S-SPEC numbers in the Intel ARK directory
+(e.g. to verify whether it supports X86-64 or not).
Backport notes:
diff -Nru intel-microcode-3.20150121.1/debian/rules intel-microcode-3.20151106.1~deb8u1/debian/rules
--- intel-microcode-3.20150121.1/debian/rules 2015-01-29 20:57:13.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/debian/rules 2015-12-28 15:57:04.000000000 -0200
@@ -15,10 +15,10 @@
# DebHelper control
export DH_ALWAYS_EXCLUDE=CVS:.svn:.git
-ifneq ($(DEB_HOST_ARCH),amd64)
-IUCODE_FILE := intel-microcode.bin
-else
+ifneq (,$(filter amd64 x32,$(DEB_HOST_ARCH)))
IUCODE_FILE := intel-microcode-64.bin
+else
+IUCODE_FILE := intel-microcode.bin
endif
# Work around Debian bug #688794
diff -Nru intel-microcode-3.20150121.1/debian/ucode-blacklist.txt intel-microcode-3.20151106.1~deb8u1/debian/ucode-blacklist.txt
--- intel-microcode-3.20150121.1/debian/ucode-blacklist.txt 2015-01-29 20:57:13.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/debian/ucode-blacklist.txt 2015-12-28 11:54:52.000000000 -0200
@@ -1,7 +1,12 @@
+06-3a-09
06-3c-01
06-3c-02
06-3c-03
+06-3d-04
06-3f-01
06-3f-02
+06-3f-04
06-45-01
06-46-01
+06-47-01
+06-56-02
diff -Nru intel-microcode-3.20150121.1/Makefile intel-microcode-3.20151106.1~deb8u1/Makefile
--- intel-microcode-3.20150121.1/Makefile 2015-01-29 20:57:13.000000000 -0200
+++ intel-microcode-3.20151106.1~deb8u1/Makefile 2015-12-28 11:54:52.000000000 -0200
@@ -4,19 +4,24 @@
IUC_QUIET_FLAGS := -q
IUC_FINAL_FLAGS := -vv
-# CUTDATE RANGE
+# CUTDATE RANGE:
+#
# This filter selects what we consider to be old microcode which
# should still be shipped even if Intel dropped them. Note that
# it is useless to ship microcodes for anything the distro doesn't
# really support anymore
#
# Watch out: check in the changelog, if this filter will add
-# microcodes that look like they've been recalled, use IUC_EXCLUDE
-# below to avoid shipping the probably recalled microcode.
+# microcodes that look like they've been recalled, use
+# IUC_OLDIES_EXCLUDE to avoid shipping the probably recalled
+# microcode. Refer to IUC_EXCLUDE for IUC_OLDIES_EXCLUDE syntax.
+#
# Last manual check: up to 2008-01-01
-IUC_OLDIES_SELECT := "--date-before=2008-01-01"
+IUC_OLDIES_SELECT := "--date-before=2008-01-01"
+IUC_OLDIES_EXCLUDE :=
# EXCLUDING MICROCODES:
+#
# Always document reason. See iucode_tool(8) for -s !<sig> syntax
# Recalls might require use of .fw overrides to retain old version,
# instead of exclusions. Exclusions have the highest priority, and
@@ -28,55 +33,95 @@
IUC_EXCLUDE += -s !0x106c0
# INCLUDING MICROCODES:
-# This should be used to add a microcode from any of the microcode
-# bundles, without the need for an override file. See iucode_tool(8)
-# for -s <sig> syntax. Always document the reason, as per IUC_EXCLUDE.
-IUC_INCLUDE :=
-
-# ##EXAMPLE ## DO NOT ENABLE##
-# 0x106a5: Xeon X55xx: Intel recalled some errata fixes for unknown
-# reasons, and then stopped shipping the microcode at rev 0x15. HP ships
-# revision 0x16 for their DL360/DL380 G6/G7 servers. Supermicro ships
-# revision 0x16 for their X8SAX/C7X58 motherboard.
#
-# IUC_INCLUDE += -s 0x000106a5
-# ##EXAMPLE##
+# This should be used to add a microcode from any of the regular
+# microcode bundles, without the need for an override file. See
+# iucode_tool(8) for -s <sig> syntax. Always document the reason,
+# as per IUC_EXCLUDE.
+IUC_INCLUDE :=
# Keep sorting order predictable or things will break
export LC_COLLATE=C
-MICROCODE_SOURCES := $(sort $(wildcard microcode-*.dat microcode-*.bin))
-MICROCODE_OVERRIDES := $(wildcard *.fw)
+MICROCODE_REG_SOURCES := $(sort $(wildcard microcode-*.dat microcode-*.bin))
+MICROCODE_SUP_SOURCES := $(wildcard supplementary-ucode-*.bin)
+MICROCODE_OVERRIDES := $(wildcard *.fw)
-MICROCODE_FINAL_SOURCES :=
+MICROCODE_FINAL_REG_SOURCES :=
ifneq ($(IUC_OLDIES_SELECT),)
- MICROCODE_FINAL_SOURCES += microcode-oldies.pbin
+ MICROCODE_FINAL_REG_SOURCES += microcode-oldies.pbin
endif
ifneq ($(IUC_INCLUDE),)
- MICROCODE_FINAL_SOURCES += microcode-extras.pbin
+ MICROCODE_FINAL_REG_SOURCES += microcode-extras.pbin
+endif
+MICROCODE_FINAL_REG_SOURCES += $(lastword $(MICROCODE_REG_SOURCES))
+
+ifneq ($(MICROCODE_SUP_SOURCES),)
+MICROCODE_FINAL_SOURCES := microcode-aux.pbin
+else
+MICROCODE_FINAL_SOURCES := $(MICROCODE_FINAL_REG_SOURCES)
endif
-MICROCODE_FINAL_SOURCES += $(lastword $(MICROCODE_SOURCES))
ifneq ($(MICROCODE_OVERRIDES),)
MICROCODE_FINAL_SOURCES += microcode-overrides.pbin
endif
all: intel-microcode.bin intel-microcode-64.bin
+# When looking for "old" microcodes that we should ship even if they
+# are not in the latest regular microcode bundle anymore, we use a
+# date filter to select *signatures* of microcodes that should be
+# included (instead of directly selecting the microcode itself).
#
-# We have to build a list of microcode signatures for very old microcode
-# that is likely to be droped as legacy from newer bundles, and then
-# select the newest microcode available for each such signature.
-#
-microcode-oldies.pbin: $(MICROCODE_SOURCES)
+# Then, the "latest" microcode (in source file order, due to the use
+# of downgrade mode) for each such signatures will be selected,
+# regardless of the date on the microcode itself.
+
+microcode-oldies.pbin: $(MICROCODE_REG_SOURCES)
@echo
- @echo Building microcode bundle for older microcode...
- @$(IUCODE_TOOL) $(IUC_FLAGS) $(IUC_OLDIES_SELECT) \
+ @echo Preprocessing older regular microcode...
+ @$(IUCODE_TOOL) $(IUC_FLAGS) \
+ $(IUC_OLDIES_SELECT) $(IUC_OLDIES_EXCLUDE) \
--loose-date-filtering --downgrade --overwrite -w "$@" $^
-microcode-extras.pbin: $(MICROCODE_SOURCES)
+microcode-extras.pbin: $(MICROCODE_REG_SOURCES)
+ @echo
+ @echo Preprocessing extra regular microcode...
+ @$(IUCODE_TOOL) $(IUC_FLAGS) -s! $(IUC_INCLUDE) \
+ --downgrade --overwrite -w "$@" $^
+
+# When there are supplementary microcode bundles, they must be merged
+# with the regular microcode in a separate step, since all such
+# microcodes must have the same precedence. We use two intermediate
+# bundles for this.
+#
+# The oldies and extra microcodes are bundled together with the latest
+# regular microcode bundle in microcode-regular.pbin. The precedence
+# order for downgrading is:
+#
+# oldies < extra < latest regular microcode bundle
+#
+# The precedence order won't matter for oldies and extra as they
+# either have different microcode, or microcode with the same
+# revision.
+#
+# Then, microcode-regular.pbin is merged with all supplementary
+# microcode bundles, with the downgrade logic disabled in the
+# microcode-aux.pbin target. The result will be used by the final
+# target.
+#
+# When there are no supplementary microcode updates, we can do all the
+# merging with the downgrade logic active in a single go in the final
+# target.
+
+microcode-regular.pbin: $(MICROCODE_FINAL_REG_SOURCES)
+ @echo
+ @echo Building microcode bundle for regular microcode...
+ @$(IUCODE_TOOL) $(IUC_FINAL_FLAGS) --downgrade --overwrite -w "$@" $^
+
+microcode-aux.pbin: microcode-regular.pbin $(MICROCODE_SUP_SOURCES)
@echo
- @echo Building microcode bundle for extra microcode...
- @$(IUCODE_TOOL) $(IUC_FLAGS) -s! $(IUC_INCLUDE) --downgrade --overwrite -w "$@" $^
+ @echo Merging regular and supplementary microcode bundles...
+ @$(IUCODE_TOOL) $(IUC_FINAL_FLAGS) --overwrite -w "$@" $^
# The microcode overrides are bundled together to sort out any
# duplication and revision level issues.
@@ -89,15 +134,19 @@
intel-microcode.bin: $(MICROCODE_FINAL_SOURCES)
@echo
@echo Building final microcode bundle...
- @$(IUCODE_TOOL) $(IUC_FINAL_FLAGS) $(IUC_EXCLUDE) --downgrade --overwrite -w "$@" $^
+ @$(IUCODE_TOOL) $(IUC_FINAL_FLAGS) $(IUC_EXCLUDE) \
+ --downgrade --overwrite -w "$@" $^
intel-microcode-64.bin: intel-microcode.bin
@echo
@echo Building stripped-down microcode bundle for x86-64 and x32...
- @$(IUCODE_TOOL) $(IUC_FINAL_FLAGS) $(shell sed -n -r -e '/^i.86/ { s/^[^ ]+ +/-s !/;s/ +\#.*//;p}' cpu-signatures.txt) $(IUC_EXCLUDE) --overwrite -w "$@" $^
+ @$(IUCODE_TOOL) $(IUC_FLAGS) \
+ $(shell sed -n -r -e '/^i.86/ { s/^[^ ]+ +/-s !/;s/ +\#.*//;p}' cpu-signatures.txt) $(IUC_EXCLUDE) \
+ --overwrite -w "$@" $^
distclean: clean
clean:
- rm -f intel-microcode-64.bin intel-microcode.bin microcode-overrides.pbin microcode-oldies.pbin microcode-extras.pbin
+ rm -f intel-microcode-64.bin intel-microcode.bin
+ rm -f microcode-overrides.pbin microcode-oldies.pbin microcode-extras.pbin microcode-regular.pbin microcode-aux.pbin
.PHONY: clean
--- End Message ---