LiveCD: missing intel microcodes

The LicveCD image for Liux does not include the latest Intel and AMD microcodes.

Symptoms when botting:
an error occurs after selecting the boot option from the UEFI boot menu:

"TSC_DEADLINE disabled due to Errata: please update microcode to version:0x22 (or later)"
(this is for some ranges of Intel CPUs/APUs; AMD, ARM, or other CPU makers have also their own microcode updates; these microcodes are recent and updated continuously to mitigate the ongoing issues in Spectre/Meltdown attacks and similar time-based side channels by using high-precision timers to detect hits or misses in hardware/software caches used by other competing threads, processes, or VMs, even on machines using very strong hypervisors).

All servers and critical machines should have these microcode updates.

So PLEASE include the microcodes and update your Live CD images to include them for Intel, AMD and ARM processors at least (x86, x86-EPT48, x64, or IA64) and ARM (32-bit or 64-bit) according to the architecture you support in each Linux live CD.

As well, without TSC_DEADLINE, there's no support for AHCI drivers, so Gparted becomes instantly unusable with the recent Linux kernels used in the currect version, that ensure that the mitigations are present. If you use a Linux kernel that includes the support for these hardware mitigations by microcode, you MUST provide these microcodes (updating the UEFI BIOS so that the UEFI platform will preload these microcode generally does not work for many and notably not by default when using secure boot mode as this changes the pre-boot platform measurement and would invalidate the existing secure boot installations): it's up to the bootloader (like EFI\bootx64.efi) or to the OS loader to load these CPU microcodes (just like they can also load microcodes for other firmwares, including GPUs/GOPs, chipsets, SATA/SCSI/USB storage adapters, Ethernet/Wifi adapters from within the OS-level drivers).

----

These microcodes may sometimes be loaded in the pre-boot firmware, but it is known to cause problems for later loading secured OSes that use mesurement, for example with Bitlocker encryptrion: these mesurements are securely hashed within TCG registers PCR[0..15], and cannot be changed by the booloader or the OS, so loading microcodes can be done only once; if you move this loading from OS to BIOS, this may work except in secured OSes (and notably on almost all servers using hypervisors, or in Windows 7/8/10 for Bitlocker using PCR[7] attachment to certify the preboot environment, and PCR[11] measurements of the booloader (as long as UEFI boot services are running).

After the bootloader (e.g. Grub for UEFI or an UEFI Shell or the Windows booloader) has terminated loading the OS, and the OS is starting (e.g. a Linux kernel or a Windows image, or an hypervisor line VMware or Hyper-V implementing its own measurements for loading virtual OSes and securing them possibly by providing them a virtual TPM), it will send an order to the UEFI boot services to be definitely unloaded to reclaim all its resources and handover the control of devices (notably drivers for PCI, LPC and USB buses) from UEFI drivers to the OS-level drivers. When the UEFI Boot services are unloaded, there's no possibility to return to it: a device shutdown has to reboot completely and pass again via the firmware preboot to make new measurements: the microcodes will no longer be present in the CPU or in other criticial devices if they have been powered off to S4/S5 state or have been reset (S4 is a bit special and used only in OSes that have support for hibernation with a specific chain of mesurements for the resume, and this bootijng method has to load again the microcodes and firmware patches, as this won't be made again by the pre-boot UEFI or UEFI booloaders that have a very different context in memory.

As far as I know sleep level S4 is not used in Linux, at least not in LiveCD; but you still need to load the necessary microcodes if they are not already present: here the TSC mesurement is critical and is checked now by the current Linux kernel: if this fails, the PC will then enter in a final hang, and will not even reply to pressing the RESET button: you must shutdown it completely from the electrical plug and remain off for several minutes to force a complete erasure or invalidation of existing RAM contents, and all devices must be fully restarted from S5 state, not from S4 state: in summary you need a true cold boot, and "fastboot" is not honored by the UEFI, and a user must also be present: this is not acceptable for servers in hosted colocations: their OS MUST support and implement the microcode loaders, and the microcode files MUST be installed and secured as well).

So update your LiveCD images to include the microcode loader and make sure you include the relevant microcode from each processor manufacturer you want to support in, Gparted: Intel, AMD, ARM... possibly others (Sun/Oracle, MIPS, ...)

These patches are included in installable (non-live) Linux installers, you dropped them and made the LiveCD unusuable on lot of machines.