622 lines
22 KiB
HTML
622 lines
22 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of IUCODE_TOOL</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>IUCODE_TOOL</H1>
|
|
Section: iucode_tool manual (8)<BR>Updated: 2018-01-28<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
iucode_tool - Tool to manipulate Intel® IA-32/X86-64 microcode bundles
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
<B>iucode_tool</B>
|
|
|
|
[<I>options</I>]
|
|
|
|
[[-t<I>type</I>] <I>filename</I>|<I>dirname</I>] ...
|
|
|
|
<A NAME="lbAD"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
<B>iucode_tool</B> is an utility that can load Intel® processor microcode
|
|
data from files in both text and binary microcode bundle formats.
|
|
<P>
|
|
|
|
It can output a list of the microcodes in these files, merge them, upload
|
|
them to the kernel (to upgrade the microcode in the system processor cores)
|
|
or write some of them out to a file in binary format for later use.
|
|
<P>
|
|
|
|
<B>iucode_tool</B> will load all microcodes in the specified files and
|
|
directories to memory, in order to process them. Duplicated and outdated
|
|
microcodes will be discarded. It can read microcode data from standard
|
|
input (<I>stdin</I>), by specifying a file name of "-" (minus sign).
|
|
<P>
|
|
|
|
Microcode data files are assumed to be in .dat text format if they have a .dat
|
|
suffix, and to be in binary format otherwise. Standard input (<I>stdin</I>) is
|
|
assumed to be in .dat text format. The <I>-t</I> option can be used to change
|
|
the type of the files specified after it, including for <I>stdin</I>.
|
|
<P>
|
|
|
|
If a directory is specified, all files whose names do not begin with a
|
|
dot will be loaded, in unspecified order. Nested directories are skipped.
|
|
<P>
|
|
|
|
Empty files and directories are ignored, and will be skipped.
|
|
<P>
|
|
|
|
You can select which microcodes should be written out, listed or uploaded
|
|
to the kernel using the
|
|
<I>-S</I>, <I>-s</I>, <I>--date-before</I> and <I>--date-after</I>
|
|
|
|
options. Should none of those options be specified, all microcodes will be
|
|
selected.
|
|
<P>
|
|
|
|
You can upload the selected microcodes to the kernel, write them out to
|
|
a file (in binary format), to a Linux early initramfs archive, to
|
|
per-processor-signature files in a directory, or to per-microcode files
|
|
in a directory using the
|
|
<I>-w</I>,
|
|
|
|
<I>--write-earlyfw</I>,
|
|
|
|
<I>-k</I>,
|
|
|
|
<I>-K</I>, and
|
|
|
|
<I>-W</I> options.
|
|
|
|
<P>
|
|
|
|
<B>iucode_tool</B> will identify microcodes in its output and error messages
|
|
using a "<I>n/k</I>" notation, where "<I>n</I>" is the bundle
|
|
number, and "<I>k</I>" is the microcode number within that bundle. The
|
|
output of the
|
|
<I>--list-all</I> option
|
|
|
|
when processing multiple input files is the best example of how it works.
|
|
<P>
|
|
<P>
|
|
|
|
For more information about Intel processor microcodes, please read the
|
|
included documentation and the Intel manuals listed in the <I>SEE ALSO</I>
|
|
section.
|
|
<P>
|
|
<A NAME="lbAE"> </A>
|
|
<H2>OPTIONS</H2>
|
|
|
|
<B>iucode_tool</B> accepts the following options:
|
|
<P>
|
|
<DL COMPACT>
|
|
<DT id="1"><B>-q</B>, <B>--quiet</B>
|
|
|
|
<DD>
|
|
Inhibit usual output.
|
|
<DT id="2"><B>-v</B>, <B>--verbose</B>
|
|
|
|
<DD>
|
|
Print more information. Use more than once for added verbosity.
|
|
<DT id="3"><B>-h</B>, <B>-?</B>, <B>--help</B>
|
|
|
|
<DD>
|
|
List all available options and their meanings.
|
|
<DT id="4"><B>--usage</B>
|
|
|
|
<DD>
|
|
Show summary of options.
|
|
<DT id="5"><B>-V</B>, <B>--version</B>
|
|
|
|
<DD>
|
|
Show version of program.
|
|
<P>
|
|
<DT id="6"><B>-t </B><I>type</I>
|
|
|
|
<DD>
|
|
Sets the file type of the following files. <I>type</I> can be:
|
|
|
|
<DL COMPACT><DT id="7"><DD>
|
|
<DL COMPACT>
|
|
<DT id="8"><B>b</B><DD>
|
|
binary format. This is the same format used by the kernel driver and the
|
|
BIOS/EFI, which is described in detail by the
|
|
<I>Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A,</I>
|
|
|
|
section 9.11.
|
|
<DT id="9"><B>d</B><DD>
|
|
Intel microcode .dat text format. This is the format normally used
|
|
by Intel to distribute microcode data files.
|
|
<DT id="10"><B>r</B><DD>
|
|
recover microcode in binary format. Search uncompressed generic binary
|
|
files for microcodes in Intel microcode binary format to recover. Note:
|
|
It can find microcode that will not pass strict checks, and thus cause
|
|
<B>iucode_tool</B> to exit if the <I>--no-strict-checks</I> or
|
|
<I>--ignore-broken</I> options are not in effect.
|
|
<DT id="11"><B>a</B><DD>
|
|
(default) <B>iucode_tool</B> will use the suffix of the file name to
|
|
select the file type: .dat text format for files that have a
|
|
<I>.dat</I>
|
|
|
|
suffix, and binary type otherwise. Note that for <I>stdin</I>, .dat
|
|
text format is assumed.
|
|
</DL>
|
|
</DL>
|
|
|
|
<P>
|
|
<DT id="12"><B>--downgrade</B>
|
|
|
|
<DD>
|
|
When multiple versions of the microcode for a specific processor are
|
|
available from different files, keep the one from the file loaded last,
|
|
regardless of revision levels. Files are always loaded in the order
|
|
they were specified in the command line. This option has no effect
|
|
when just one file has been loaded.
|
|
<P>
|
|
<DT id="13"><B>--no-downgrade</B>
|
|
|
|
<DD>
|
|
When multiple versions of the microcode for a specific processor are
|
|
available from different files, keep the one with the highest revision
|
|
level. This is the default mode of operation.
|
|
<P>
|
|
<DT id="14"><B>--strict-checks</B>
|
|
|
|
<DD>
|
|
Perform strict checks on the microcode data. It will refuse to load
|
|
microcodes and microcode data files with unexpected size and metadata. It
|
|
will also refuse to load microcode entries that have the same metadata, but
|
|
different payload. This is the default mode of operation.
|
|
<P>
|
|
<DT id="15"><B>--no-strict-checks</B>
|
|
|
|
<DD>
|
|
Perform less strict checks on the microcode data. Use only if you happen
|
|
to come across a microcode data file that has microcodes with weird sizes
|
|
or incorrect non-critical metadata (such as invalid dates), which you want
|
|
to retain. If you just want to skip those, use the <I>--ignore-broken</I>
|
|
option.
|
|
<P>
|
|
<DT id="16"><B>--ignore-broken</B>
|
|
|
|
<DD>
|
|
Skip broken microcode entries when loading a microcode data file, instead
|
|
of aborting program execution. If the microcode entry has an unsupported
|
|
format or had its header severely corrupted, all remaining data in the file
|
|
will have to be ignored. In that case, using a file type of <I>recover
|
|
microcode in binary format</I> (<I>-tr</I> option) is recommended, as it
|
|
can skip over badly mangled microcode data.
|
|
<P>
|
|
<DT id="17"><B>--no-ignore-broken</B>
|
|
|
|
<DD>
|
|
Abort program execution if a broken microcode is found while loading a
|
|
microcode data file. This is the default mode of operation.
|
|
<P>
|
|
<P>
|
|
<DT id="18"><B>-s ! | [!]</B><I>signature</I><B>[,[</B><I>pf_mask</I><B>][,[</B><I>lt:</I><B>|</B><I>eq:</I><B>|</B><I>gt:</I><B>]</B><I>revision</I><B>]]</B>
|
|
|
|
<DD>
|
|
Select microcodes by the specified <I>signature</I>, <I>processor flags mask</I>
|
|
(<I>pf_mask</I>), and <I>revision</I>.
|
|
<P>
|
|
If the <I>processor flags mask</I> is specified, it will select only microcodes
|
|
that are suitable for at least one of the processor flag combinations present
|
|
in the mask.
|
|
<P>
|
|
If the <I>revision</I> is specified, optionally prefixed by one of the
|
|
"<I>eq:</I>", "<I>lt:</I>" or "<I>gt:</I>" operators, it will
|
|
select only microcodes that have that same <I>revision</I> (if no operator, or
|
|
if the "<I>eq:</I>" operator is used), or microcodes that have a
|
|
<I>revision</I> that is less than ("<I>lt:</I>" operator), or greater than
|
|
("<I>gt:</I>" operator), the one specified.
|
|
<P>
|
|
Specify more than once to select more microcodes. This option can be combined
|
|
with the <I>--scan-system</I> option to select more microcodes. If
|
|
<I>signature</I> is prefixed with a "<I>!</I>" (exclamation mark), it will
|
|
deselect microcodes instead. Ordering matters, with later <I>-s</I> options
|
|
overriding earlier ones, including <I>--scan-system</I>.
|
|
<P>
|
|
When specifying <I>signature</I> and <I>pf_mask</I>, hexadecimal numbers must be
|
|
prefixed with "<I>0x</I>", and octal numbers with "<I>0</I>".
|
|
Decimal numbers must not have leading zeros, otherwise they would be
|
|
interpreted as octal numbers.
|
|
<P>
|
|
The special notation <I>-s!</I> (with no <I>signature</I> parameter) instructs
|
|
<B>iucode_tool</B> to require explicit inclusion of microcode signatures (using
|
|
the non-negated form of <I>-s</I>, or using <I>--scan-system</I>).
|
|
<P>
|
|
<DT id="19"><B>-S</B>, <B>--scan-system</B>[=<I>mode</I>]
|
|
|
|
<DD>
|
|
Select microcodes by scanning online processors on this system for their
|
|
signatures.
|
|
<P>
|
|
This option can be used only once, and it can be combined with the <I>-s</I>
|
|
option to select more microcodes. The microcodes selected by
|
|
<I>--scan-system</I> can also be deselected by a later <I>-s !signature</I>
|
|
option.
|
|
<P>
|
|
The optional <I>mode</I> argument (accepted only by the long version of the
|
|
option) selects the strategy used to scan processors:
|
|
<DL COMPACT><DT id="20"><DD>
|
|
<DL COMPACT>
|
|
<DT id="21"><B>0</B> or <B>auto</B><DD>
|
|
Currently the same as <B>fast</B>, but this might change in future versions if
|
|
Intel ever deploys multi-signature systems that go beyond mixed-stepping. This
|
|
is the default mode of operation, for backwards compatibility
|
|
with previous versions of <B>iucode_tool</B>.
|
|
<DT id="22"><B>1</B> or <B>fast</B><DD>
|
|
Uses the cpuid instruction to detect the signature of the processor
|
|
<B>iucode_tool</B> is running on, and selects all steppings for that processor's
|
|
type, family and model. Supports mixed-stepping systems.
|
|
<DT id="23"><B>2</B> or <B>exact</B><DD>
|
|
Uses kernel drivers to scan the signature of every online processor directly.
|
|
This mode supports multi-signature systems. This scan mode will be slow on
|
|
large systems with many processors, and likely requires special permissions
|
|
(such as running as the root user). Should the scan fail for any reason, as
|
|
a fail-safe measure, it will issue an warning and consider all possible
|
|
steppings for every signature it did manage to scan successfully.
|
|
</DL>
|
|
</DL>
|
|
|
|
<P>
|
|
<DT id="24"><B>--date-before</B>=<I>YYYY-MM-DD</I> and <B>--date-after</B>=<I>YYYY-MM-DD</I><DD>
|
|
Limit the selected microcodes by a date range. The date must be given in ISO
|
|
format, with four digits for the year and two digits for the month and day and
|
|
"<I>-</I>" (minus sign) for the separator. Dates are not range-checked,
|
|
so you can use <I>--date-after=2000-00-00</I> to select all microcodes
|
|
dated since January 1st, 2000.
|
|
<P>
|
|
<DT id="25"><B>--loose-date-filtering</B>
|
|
|
|
<DD>
|
|
When a date range is specified, all revisions of the microcode will be
|
|
considered for selection (ignoring just the date range, all other filters still
|
|
apply) should any of the microcode's revisions be within the date range.
|
|
<P>
|
|
<DT id="26"><B>--strict-date-filtering</B>
|
|
|
|
<DD>
|
|
When a date range is specified, select only microcodes which are within the
|
|
date range. This is the default mode of operation.
|
|
<P>
|
|
<DT id="27"><B>-l</B>, <B>--list</B>
|
|
|
|
<DD>
|
|
List selected microcode signatures to standard output (<I>stdout</I>).
|
|
<DT id="28"><B>-L</B>, <B>--list-all</B>
|
|
|
|
<DD>
|
|
List all microcode signatures while they're being processed to standard output
|
|
(<I>stdout</I>).
|
|
<P>
|
|
<DT id="29"><B>-k</B>[<I>device</I>], <B>--kernel</B>[=<I>device</I>]
|
|
|
|
<DD>
|
|
Upload selected microcodes to the kernel. Optionally, the device path can be
|
|
specified (default:
|
|
<I>/dev/cpu/microcode</I>). This update method is deprecated:
|
|
|
|
it will be removed eventually from the kernel and from iucode_tool.
|
|
<DT id="30"><B>-K</B>[<I>directory</I>], <B>--write-firmware</B>[=<I>directory</I>]
|
|
|
|
<DD>
|
|
Write selected microcodes with the file names expected by the Linux kernel
|
|
firmware loader. Optionally, the destination directory can be specified
|
|
(default: <I>/lib/firmware/intel-ucode</I>).
|
|
|
|
<P>
|
|
<DT id="31"><B>-w</B><I>file</I>, <B>--write-to</B>=<I>file</I>
|
|
|
|
<DD>
|
|
Write selected microcodes to a file in binary format.
|
|
<P>
|
|
<DT id="32"><B>--write-earlyfw</B>=<I>file</I>
|
|
|
|
<DD>
|
|
Write selected microcodes to an early initramfs archive, which should be
|
|
prepended to the regular initramfs to allow the kernel to update processor
|
|
microcode very early during system boot.
|
|
<P>
|
|
<DT id="33"><B>-W</B><I>directory</I>, <B>--write-named-to</B>=<I>directory</I>
|
|
|
|
<DD>
|
|
Write selected microcodes to the specified directory, one microcode per
|
|
file, in binary format. The file names reflect the microcode signature,
|
|
processor flags mask and revision.
|
|
<P>
|
|
<DT id="34"><B>--write-all-named-to</B>=<I>directory</I>
|
|
|
|
<DD>
|
|
Write every microcode to the specified directory, one microcode per file,
|
|
in binary format. The file names reflect the microcode signature,
|
|
processor flags mask and revision. This is the only way to write out every
|
|
revision of the same microcode.
|
|
<P>
|
|
<DT id="35"><B>--overwrite</B>
|
|
|
|
<DD>
|
|
Remove the destination file before writing, if it exists and is not a
|
|
directory. The destination file is not overwritten in-place. Hardlinks
|
|
will be severed, and any existing access permissions, ACLs and other
|
|
extended attributes of the old destination file will be lost.
|
|
<P>
|
|
<DT id="36"><B>--no-overwrite</B>
|
|
|
|
<DD>
|
|
Abort if the destination file already exists. This is the default mode of
|
|
operation. Do note that iucode_tool does not follow non-directory symlinks
|
|
when writing files.
|
|
<P>
|
|
<DT id="37"><B>--mini-earlyfw</B>
|
|
|
|
<DD>
|
|
Optimize the early initramfs cpio container for minimal size. It will
|
|
change the cpio block size to 16 bytes, and remove header entries for the
|
|
parent directories of the microcode data file. As a result, the microcode
|
|
data file will not be available to the regular initramfs, and tools might
|
|
complain about the non-standard cpio block size.
|
|
<P>
|
|
This will typically reduce the early initramfs size by 736 bytes.
|
|
<P>
|
|
<DT id="38"><B>--normal-earlyfw</B>
|
|
|
|
<DD>
|
|
Optimize the early initramfs size for tool compatibility. This is the
|
|
default mode of operation. The microcode data file will be available
|
|
inside the regular initramfs as well.
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H2>NOTES</H2>
|
|
|
|
<P>
|
|
<B>iucode_tool</B> reads all data to memory before doing any processing. It
|
|
enforces a sanity limit of a maximum of 1GiB worth of binary microcode data
|
|
per microcode data file.
|
|
<P>
|
|
<P>
|
|
|
|
All informational and error messages are sent to standard error
|
|
(<I>stderr</I>), while user-requested output (such as output generated by
|
|
the list options) is sent to standard output (<I>stdout</I>).
|
|
<P>
|
|
<P>
|
|
|
|
<B>iucode_tool</B> creates files with permissions 0644 (rw-r--r--),
|
|
modified by the current umask.
|
|
<P>
|
|
<P>
|
|
|
|
<B>iucode_tool</B>'s selected microcode listing and microcode output files
|
|
are sorted first by <I>processor signature</I> (in ascending order), and
|
|
then by <I>processor flags mask</I> (in descending order).
|
|
<P>
|
|
<P>
|
|
|
|
When multiple revisions of a microcode are selected, the older ones will
|
|
be skipped. Only the newest selected revision of a microcode (or the
|
|
last one in load order when the <I>--downgrade</I> option is active) will
|
|
be written to a file or uploaded to the kernel.
|
|
<P>
|
|
<P>
|
|
|
|
Intel microcode data files, both in binary and text formats, can be
|
|
concatenated to generate a bigger and still valid microcode data file.
|
|
<P>
|
|
<P>
|
|
|
|
<B>iucode_tool</B> does not follow symlinks when writing microcode data
|
|
files. It will either refuse to write the file and abort (default mode
|
|
of operation), or (when the <I>--overwrite</I> option is active) it will
|
|
remove the target symlink or file (and therefore breaking hardlinks)
|
|
<I>before</I> writing the new file.
|
|
<P>
|
|
<P>
|
|
|
|
<B>iucode_tool</B> does follow directory symlinks to locate the directory
|
|
to write files into.
|
|
<P>
|
|
<A NAME="lbAG"> </A>
|
|
<H3>Linux Notes</H3>
|
|
|
|
Before Linux v4.4, the microcode update driver was split in two parts: the
|
|
early microcode update driver (which gets microcode data from the
|
|
initramfs) and the late microcode update driver, which could be a module
|
|
and got microcode data from the firmware subsystem. The two drivers were
|
|
unified in Linux v4.4.
|
|
<P>
|
|
The microcode update driver needs to be present in the system at all times
|
|
to ensure microcode updates are reapplied on resume from suspend and CPU
|
|
hotplug. Do not unload the microcode module, unless you really know
|
|
better. Since Linux v4.4, the late microcode driver cannot be a module
|
|
anymore and will always be present in the system when enabled.
|
|
<P>
|
|
Updating microcode early is safer. It can only be done at boot and it
|
|
requires an initramfs, but it is strongly recommended: late microcode
|
|
updates (which read microcode data from /lib/firmware) cannot safely change
|
|
visible processor features.
|
|
<P>
|
|
Early microcode updates are available since Linux v3.9. They can safely
|
|
change visible processor features (such as the microcode updates that
|
|
disabled Intel TSX instructions on Intel Haswell cores do). They require
|
|
an uncompressed initramfs image with the microcode update data in
|
|
<I>/kernel/x86/microcode/GenuineIntel.bin</I>. This uncompressed initramfs
|
|
image must come before any compressed initramfs image(s), and it has an
|
|
special name: <I>early initramfs</I>.
|
|
<P>
|
|
The microcode update data inside the early initramfs image must be aligned
|
|
to a 16-byte boundary due to a bug in several versions of the Linux kernel
|
|
early microcode update driver. This requires special steps when creating
|
|
the initramfs archive with the microcode data, and will be handled
|
|
automatically by the <B>iucode_tool</B> <I>--write-earlyfw</I> option.
|
|
<P>
|
|
Since Linux v4.2, it is also possible to build a kernel with the microcode
|
|
update data as built-in firmware, using the CONFIG_FIRMWARE_IN_KERNEL
|
|
facility. This feature is not yet mature as of Linux v4.2.8, v4.4.11,
|
|
v4.5.5 and v4.6, and might not work in every case.
|
|
<P>
|
|
The <I>/dev/cpu/microcode</I> update interface has been deprecated and
|
|
should not be used. It has one special requirement: each write syscall
|
|
must contain whole microcode(s). It can be accessed through
|
|
<B>iucode_tool</B> <I>--kernel</I>.
|
|
<P>
|
|
Up to Linux v3.5, late microcode updates were required to be triggered
|
|
per-core, by writing the number 1 to
|
|
<I>/sys/devices/system/cpu/*/microcode/reload</I> for every cpu. Depending
|
|
on kernel version, you must either trigger it on every core to avoid a
|
|
dangerous situation where some cores are using outdated microcode, or the
|
|
kernel will accept the request only for the boot processor and use it to
|
|
trigger an update on all system processor cores.
|
|
<P>
|
|
Since Linux v3.6, the late microcode update driver has a new interface
|
|
that explicitly triggers an update for every core at once when the number
|
|
1 is written to <I>/sys/devices/system/cpu/microcode/reload</I>.
|
|
<P>
|
|
<A NAME="lbAH"> </A>
|
|
<H2>EXAMPLES</H2>
|
|
|
|
<A NAME="lbAI"> </A>
|
|
<H3>Updating files in <I>/lib/firmware/intel-ucode</I>:</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="39">
|
|
<DD>iucode_tool -K/lib/firmware/intel-ucode \
|
|
<BR>
|
|
|
|
<TT> </TT>/lib/firmware/intel-ucode \<BR>
|
|
<BR>
|
|
|
|
<TT> </TT>/tmp/file-with-new-microcodes.bin<BR>
|
|
</DL>
|
|
<A NAME="lbAJ"> </A>
|
|
<H3>Processing several compressed files at once:</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="40">
|
|
<DD>zcat intel-microcode*.dat.gz | iucode_tool -l -
|
|
<DT id="41">
|
|
<DD>zcat intel-microcode*.bin.gz | iucode_tool -l -tb -
|
|
</DL>
|
|
<A NAME="lbAK"> </A>
|
|
<H3>Selecting microcodes and creating an early initramfs:</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="42">
|
|
<DD>iucode_tool --scan-system \
|
|
<BR>
|
|
|
|
<TT> </TT>--write-earlyfw=/tmp/early.cpio \<BR>
|
|
<BR>
|
|
|
|
<TT> </TT>/lib/firmware/intel-ucode<BR>
|
|
<DT id="43">
|
|
<DD>iucode_tool -s 0x106a5 -s 0x106a4 -l /lib/firmware/intel-ucode
|
|
</DL>
|
|
<A NAME="lbAL"> </A>
|
|
<H3>Using the recovery loader to load and to update microcode in an early initramfs:</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="44">
|
|
<DD>iucode_tool -L -tr /boot/intel-ucode.img
|
|
<DT id="45">
|
|
<DD>iucode_tool -Ll -S --write-earlyfw=/boot/intel-ucode.img.new \
|
|
<BR>
|
|
|
|
<TT> </TT>-tr /boot/intel-ucode.img -tb /lib/firmware/intel-ucode && \<BR>
|
|
<BR>
|
|
|
|
mv /boot/intel-ucode.img.new /boot/intel-ucode.img
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbAM"> </A>
|
|
<H2>BUGS</H2>
|
|
|
|
Microcode with negative revision numbers is not special-cased, and will not be
|
|
preferred over regular microcode.
|
|
<P>
|
|
<P>
|
|
|
|
The <I>downgrade mode</I> should be used only for microcodes with the same
|
|
<I>processor flags mask</I>. It cannot handle the corner cases where
|
|
modifying a <I>processor flags mask</I> would be required to force the
|
|
kernel to load a lower revision of a microcode, and <B>iucode_tool</B> will
|
|
issue an warning when that happens. So far, this has not proved to be a
|
|
relevant limitation as changes to the <I>processor flags mask</I> of
|
|
post-launch, production microcode updates are very rare.
|
|
<P>
|
|
<P>
|
|
|
|
The <I>loader version</I> microcode metadata field is ignored by
|
|
<B>iucode_tool</B>. This shouldn't cause problems as long as the same signature
|
|
never needs more than a single type of loader.
|
|
<P>
|
|
<P>
|
|
|
|
Files are not replaced atomically: if <B>iucode_tool</B> is interrupted while
|
|
writing to a file, that file will be corrupted.
|
|
<P>
|
|
<A NAME="lbAN"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
<B>The Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A:
|
|
System Programming Guide, Part 1</B> (order number 253668), section 9.11.
|
|
|
|
|
|
<A NAME="lbAO"> </A>
|
|
<H2>AUTHOR</H2>
|
|
|
|
Henrique de Moraes Holschuh <<A HREF="mailto:hmh@hmh.eng.br">hmh@hmh.eng.br</A>>
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="46"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="47"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="48"><A HREF="#lbAD">DESCRIPTION</A><DD>
|
|
<DT id="49"><A HREF="#lbAE">OPTIONS</A><DD>
|
|
<DT id="50"><A HREF="#lbAF">NOTES</A><DD>
|
|
<DL>
|
|
<DT id="51"><A HREF="#lbAG">Linux Notes</A><DD>
|
|
</DL>
|
|
<DT id="52"><A HREF="#lbAH">EXAMPLES</A><DD>
|
|
<DL>
|
|
<DT id="53"><A HREF="#lbAI">Updating files in <I>/lib/firmware/intel-ucode</I>:</A><DD>
|
|
<DT id="54"><A HREF="#lbAJ">Processing several compressed files at once:</A><DD>
|
|
<DT id="55"><A HREF="#lbAK">Selecting microcodes and creating an early initramfs:</A><DD>
|
|
<DT id="56"><A HREF="#lbAL">Using the recovery loader to load and to update microcode in an early initramfs:</A><DD>
|
|
</DL>
|
|
<DT id="57"><A HREF="#lbAM">BUGS</A><DD>
|
|
<DT id="58"><A HREF="#lbAN">SEE ALSO</A><DD>
|
|
<DT id="59"><A HREF="#lbAO">AUTHOR</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:13 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|