1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
|
intel-microcode for Debian
--------------------------
Introduction:
Intel® 64 and IA-32 processors (x86_64 and i686 processors) are capable of
field-upgrading their control program (microcode) as well as parameters
for other on-chip subsystems (power management, interconnects, etc).
These microcode updates correct processor errata, and are important for
safe, stable and correct system operation.
While most of the microcode updates fix problems that happen extremely
rarely, they also fix high-profile, high-hitting issues. There are enough
microcode updates fixing processor errata that would cause system lockup,
memory corruption, or unpredictable system behavior, to warrant taking
firmware updates and microcode updates seriously.
Microcode updates are ephemeral: they will be lost after a processor hard
reset or after the processor is powered off. They must be reapplied at
every boot, as well as after the system wakes up from suspend to RAM or
disk.
Updating the processor microcode is the responsibility of the system
firmware (BIOS, UEFI). However, not all vendors will release timely
updates for their firmware when Intel releases updated microcode, and most
users don't update their system firmware in a timely fashion (or at all)
anyway.
The end result is that, unless the operating system picks up the slack and
tries to deliver microcode updates, the processor in many systems will be
running with outdated microcode, increasing the chances of incorrect
system operation.
Using Debian to apply microcode updates:
Debian can apply microcode updates to the system processors during the
operating system boot when a correctly configured Linux kernel (such as
the standard Debian Linux kernels), and a small set of extra packages from
"non-free" and "contrib" are installed.
You must have "contrib" and "non-free" repositories enabled in apt's
sources list (either in /etc/apt/sources.list, or in a file inside
/etc/apt/sources.list.d/).
On a default Debian system (which uses a Debian kernel, the grub
bootloader, and initramfs-tools to create the initramfs for the kernel),
install the "intel-microcode" package and its dependencies, and reboot.
Users of custom configurations should note that microcode update support
for Debian 8 "Jessie" changed from previous Debian stable releases.
Custom Linux kernels must be built with initramfs support enabled (Kconfig
option CONFIG_BLK_DEV_INITRD=y), as well as early microcode support
enabled (Kconfig options CONFIG_MICROCODE=y, CONFIG_MICROCODE_INTEL=y,
CONFIG_MICROCODE_INTEL_EARLY=y). An initramfs image *must* be used.
The use of "dracut" to generate the initramfs is not yet supported, but it
should work if you have a new enough version of dracut that is compatible
with the kernel you are using (i.e. it might require the use of
backports). Dracut will have to be manually configured to enable early
microcode updates. Better dracut support is planned for a future version
of the intel-microcode package.
NOTE: It is not impossible for an operating-system supplied microcode
update to cause boot issues. Should that happen, please refer to the
"RECOVERY PROCEDURE" section of this document.
Caveats:
Please keep your UEFI/BIOS up-to-date. Assuming your motherboard vendor
does a good job of updating system firmware components, an up-to-date
version of the firmware will negate most of the caveats listed here.
Some features added to the processor post-launch, such as Intel SGX for
"Skylake", are likely to require a full firmware update to work. Some
issues and errata can only be fixed by a full firmware update should they
require fixes and workarounds outside of the processor microcode update
(typically: ME firmware, SMM code, platform MSR setup, ACPI data, Intel
TXT/SGX modules).
A microcode update may enable functionality or change the behavior of
weakly-defined functionality (such as the effect of model-dependent CPU
power-management MSRs). This can (very rarely) interact badly with
outdated BIOS/UEFI.
A microcode update can revoke the signatures of vulnerable Intel TXT ACMs
(refer to security advisory INTEL-SA-00035) and Intel SGX system modules.
This will disable Intel TXT and Intel SGX in a system that still has the
vulnerable components in firmware (the only way to really fix the
vulnerabilities is to update the firmware).
Microcode updates often do not go well with overclocking and similar
tuning (such as underclocking, "undervolting", etc). Reset the system to
Intel's *up-to-date* recommended values should a microcode update seem to
be causing trouble, and search for a less aggressive, stable operating
point for the new microcode.
A microcode update can (very rarely) interact badly with, or expose
software bugs in the kernel and on frequency/thermal control daemons.
RECOVERY PROCEDURE:
It is possible for a microcode update to not work well, or to not work at
all on specific system models. This is very rare when using early
microcode updates, but it has happened at least once.
Should you experience problems because of the microcode update, you will
have to bypass the microcode update process that happens during operating
system startup (boot), and remove (or install an older version of) the
intel-microcode package.
To bypass the microcode update during system startup, you must instruct the
boot loader (grub, lilo, etc) to pass the "dis_ucode_ldr" parameter
(without the quotes) to the kernel.
If your system uses grub (the default bootloader in Debian):
1. Access the grub menu during boot (press and hold the left "Shift"
key right after starting the system up if you don't see a grub menu
during boot);
2. Move the highlight/cursor to the kernel/boot option you want to
use, and press the "e" key to edit it;
3. Locate the line that starts with "linux" using the cursor
keys. You must add the word "dis_ucode_ldr" (without the quotes) to
the end of that line;
4. Press "Ctrl+X" to start (boot) the system. The microcode updates
will be skipped.
After the system is running, remove or purge the intel-microcode package,
or alternatively install an older version of the intel-microcode package.
If removing or purging the intel-microcode package fails to do it for some
reason, please refresh the initramfs using the "update-initramfs -u"
command (as the root user), and possibly "update-initramfs -u -k <desired
kernel version>" or "update-initramfs -u -k all".
Please report any issues caused by microcode updates to the Debian bug
tracker, e.g. using the "reportbug" tool.
Microcode update details:
The "early mode" of the Linux kernel microcode update driver will apply
the microcode updates as soon as possible, before making use of the more
complex modes and functionality of the system processors. This greatly
reduces the chances of system malfunction due to any issues that are
corrected by the microcode update.
It will update the CPU core that boots the system (known as BSP, for
"bootstrap processor") as one of the first things it does. It will also
update the microcode on the other CPU cores (known as AP, for "application
processor") while enabling them, before they can be used.
In some cases, early microcode updates will allow the kernel to sidestep
the need to disable functionality, as an example, there's the "Atom PSE
erratum".
In other cases, it will be the only safe way to apply a microcode update.
For example, the Intel TSX errata in Intel Haswell and Broadwell processors
required a microcode update that entirely disables Intel TSX. Applying the
microcode update will crash anything that might be using Intel TSX at that
time.
The initramfs helpers will attempt to restrict the number of microcode
updates added to the initramfs to the bare minimum through the use of
iucode_tool. This behavior can be changed and fine-tuned through the
/etc/default/intel-microcode file.
Also, microcode from files matching /usr/share/misc/intel-microcode* will
be considered. This allows the easy use of microcode.dat files distributed
directly by Intel. Be careful to not leave old files there, or you may end
up using microcode that Intel stopped distributing on purpose for unknown
reasons.
Downloading new microcode data from Intel:
A new version of the microcode bundle can be downloaded directly from
Intel (through their GitHub project):
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
To manually install the downloaded microcode bundle, unpack the archive you
got from Intel and copy the microcode-*.dat file from the archive to
/usr/share/misc/intel-microcode.dat.
You should make sure the microcode data file is owned by root, and that it
can only be written to by root (e.g. mode 0644) for security reasons:
chown root:root /usr/share/misc/intel-microcode.dat
chmod 0644 /usr/share/misc/intel-microcode.dat
After you install the updated intel-microcode.dat file, run as root:
update-initramfs -u
The intel-microcode package supports "extra" microcode data in the
following files (and will warn you if it detects and use them):
/usr/share/misc/intel-microcode*
both .dat and .bin formats are supported.
Triggering an immediate microcode update (without a reboot):
**** WARNING **** **** WARNING **** **** WARNING **** **** WARNING ****
This procedure used to be safe before microcode update 20140913.
It is not safe anymore in the general case.
While it is likely to continue to be safe for the Intel micro-
architectures that preceded Haswell and Silvermont, this is not
in any way assured.
You have been warned. Do not do this unless you really know
what you are doing.
**** WARNING **** **** WARNING **** **** WARNING **** **** WARNING ****
The microcode kernel module will attempt to apply a microcode update when
loaded by "modprobe". If the module is already loaded or compiled-in (it
cannot be a module anymore in recent Linux kernels), run this command (as
root):
echo -n 1 >/sys/devices/system/cpu/microcode/reload
For kernels before Linux v3.6, refer to the iucode_tool(8) manpage.
* Note: Intel is a registered trademark of Intel Corporation.
-- Henrique de Moraes Holschuh <hmh@debian.org> Sun, 10 Apr 2016 16:32:09 -0300
|
