Adding debian version 3.20240312.1.debian/3.20240312.1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 239 insertions, 0 deletions

diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 0000000..220932d
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,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