Changes in old_microcode.rst

f088104d837a991c65e51fa30bb4196169b3244d - Merge drm/drm-next into drm-intel-gt-next

Tue, 16 Sep 2025 12:53:20 +0200

Merge drm/drm-next into drm-intel-gt-nextBackmerge in order to get the commit: 048832a3f400 ("drm/i915: Refactor shmem_pwrite() to use kiocb and write_iter")To drm-intel-gt-next as there are followup fixes to be applied.Signed-off-by: Joonas Lahtinen List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

ab93e0dd72c37d378dd936f031ffb83ff2bd87ce - Merge branch 'next' into for-linus

Wed, 06 Aug 2025 19:08:54 +0200

Merge branch 'next' into for-linusPrepare input updates for 6.17 merge window. List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

a7bee4e7f78089c101be2ad51f4b5ec64782053e - Merge tag 'ib-mfd-gpio-input-pwm-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into next

Mon, 04 Aug 2025 08:28:48 +0200

Merge tag 'ib-mfd-gpio-input-pwm-v6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into nextMerge an immutable branch between MFD, GPIO, Input and PWM to resolveconflicts for the merge window pull request. List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

74f1af95820fc2ee580a775a3a17c416db30b38c - Merge remote-tracking branch 'drm/drm-next' into msm-next

Sun, 29 Jun 2025 04:54:49 +0200

Merge remote-tracking branch 'drm/drm-next' into msm-nextBack-merge drm-next to (indirectly) get arm-smmu updates for makingstall-on-fault more reliable.Signed-off-by: Rob Clark List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

c598d5eb9fb331ba17bc9ad67ae9a2231ca5aca5 - Merge drm/drm-next into drm-misc-next

Wed, 11 Jun 2025 09:01:34 +0200

Merge drm/drm-next into drm-misc-nextBackmerging to forward to v6.16-rc1Signed-off-by: Thomas Zimmermann List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

86e2d052c2320bf12571a5d96b16c2745e1cfc5e - Merge drm/drm-next into drm-xe-next

Mon, 09 Jun 2025 18:26:55 +0200

Merge drm/drm-next into drm-xe-nextBackmerging to bring in 6.16Signed-off-by: Thomas Hellström List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

34c55367af96f62e89221444f04487440ebc6487 - Merge drm/drm-next into drm-intel-next

Mon, 09 Jun 2025 11:40:46 +0200

Merge drm/drm-next into drm-intel-nextSync to v6.16-rc1, among other things to get the fixed size GENMASK_U*()and BIT_U*() macros.Signed-off-by: Jani Nikula List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

785cdec46e9227f9433884ed3b436471e944007c - Merge tag 'x86-core-2025-05-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Tue, 27 May 2025 01:04:17 +0200

Merge tag 'x86-core-2025-05-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipPull core x86 updates from Ingo Molnar: "Boot code changes: - A large series of changes to reorganize the x86 boot code into a better isolated and easier to maintain base of PIC early startup code in arch/x86/boot/startup/, by Ard Biesheuvel. Motivation & background: | Since commit | | c88d71508e36 ("x86/boot/64: Rewrite startup_64() in C") | | dated Jun 6 2017, we have been using C code on the boot path in a way | that is not supported by the toolchain, i.e., to execute non-PIC C | code from a mapping of memory that is different from the one provided | to the linker. It should have been obvious at the time that this was a | bad idea, given the need to sprinkle fixup_pointer() calls left and | right to manipulate global variables (including non-pointer variables) | without crashing. | | This C startup code has been expanding, and in particular, the SEV-SNP | startup code has been expanding over the past couple of years, and | grown many of these warts, where the C code needs to use special | annotations or helpers to access global objects. This tree includes the first phase of this work-in-progress x86 boot code reorganization. Scalability enhancements and micro-optimizations: - Improve code-patching scalability (Eric Dumazet) - Remove MFENCEs for X86_BUG_CLFLUSH_MONITOR (Andrew Cooper) CPU features enumeration updates: - Thorough reorganization and cleanup of CPUID parsing APIs (Ahmed S. Darwish) - Fix, refactor and clean up the cacheinfo code (Ahmed S. Darwish, Thomas Gleixner) - Update CPUID bitfields to x86-cpuid-db v2.3 (Ahmed S. Darwish) Memory management changes: - Allow temporary MMs when IRQs are on (Andy Lutomirski) - Opt-in to IRQs-off activate_mm() (Andy Lutomirski) - Simplify choose_new_asid() and generate better code (Borislav Petkov) - Simplify 32-bit PAE page table handling (Dave Hansen) - Always use dynamic memory layout (Kirill A. Shutemov) - Make SPARSEMEM_VMEMMAP the only memory model (Kirill A. Shutemov) - Make 5-level paging support unconditional (Kirill A. Shutemov) - Stop prefetching current->mm->mmap_lock on page faults (Mateusz Guzik) - Predict valid_user_address() returning true (Mateusz Guzik) - Consolidate initmem_init() (Mike Rapoport) FPU support and vector computing: - Enable Intel APX support (Chang S. Bae) - Reorgnize and clean up the xstate code (Chang S. Bae) - Make task_struct::thread constant size (Ingo Molnar) - Restore fpu_thread_struct_whitelist() to fix CONFIG_HARDENED_USERCOPY=y (Kees Cook) - Simplify the switch_fpu_prepare() + switch_fpu_finish() logic (Oleg Nesterov) - Always preserve non-user xfeatures/flags in __state_perm (Sean Christopherson) Microcode loader changes: - Help users notice when running old Intel microcode (Dave Hansen) - AMD: Do not return error when microcode update is not necessary (Annie Li) - AMD: Clean the cache if update did not load microcode (Boris Ostrovsky) Code patching (alternatives) changes: - Simplify, reorganize and clean up the x86 text-patching code (Ingo Molnar) - Make smp_text_poke_batch_process() subsume smp_text_poke_batch_finish() (Nikolay Borisov) - Refactor the {,un}use_temporary_mm() code (Peter Zijlstra) Debugging support: - Add early IDT and GDT loading to debug relocate_kernel() bugs (David Woodhouse) - Print the reason for the last reset on modern AMD CPUs (Yazen Ghannam) - Add AMD Zen debugging document (Mario Limonciello) - Fix opcode map (!REX2) superscript tags (Masami Hiramatsu) - Stop decoding i64 instructions in x86-64 mode at opcode (Masami Hiramatsu) CPU bugs and bug mitigations: - Remove X86_BUG_MMIO_UNKNOWN (Borislav Petkov) - Fix SRSO reporting on Zen1/2 with SMT disabled (Borislav Petkov) - Restructure and harmonize the various CPU bug mitigation methods (David Kaplan) - Fix spectre_v2 mitigation default on Intel (Pawan Gupta) MSR API: - Large MSR code and API cleanup (Xin Li) - In-kernel MSR API type cleanups and renames (Ingo Molnar) PKEYS: - Simplify PKRU update in signal frame (Chang S. Bae) NMI handling code: - Clean up, refactor and simplify the NMI handling code (Sohil Mehta) - Improve NMI duration console printouts (Sohil Mehta) Paravirt guests interface: - Restrict PARAVIRT_XXL to 64-bit only (Kirill A. Shutemov) SEV support: - Share the sev_secrets_pa value again (Tom Lendacky) x86 platform changes: - Introduce the header namespace (Ingo Molnar) - i2c: piix4, x86/platform: Move the SB800 PIIX4 FCH definitions to (Mario Limonciello) Fixes and cleanups: - x86 assembly code cleanups and fixes (Uros Bizjak) - Misc fixes and cleanups (Andi Kleen, Andy Lutomirski, Andy Shevchenko, Ard Biesheuvel, Bagas Sanjaya, Baoquan He, Borislav Petkov, Chang S. Bae, Chao Gao, Dan Williams, Dave Hansen, David Kaplan, David Woodhouse, Eric Biggers, Ingo Molnar, Josh Poimboeuf, Juergen Gross, Malaya Kumar Rout, Mario Limonciello, Nathan Chancellor, Oleg Nesterov, Pawan Gupta, Peter Zijlstra, Shivank Garg, Sohil Mehta, Thomas Gleixner, Uros Bizjak, Xin Li)"* tag 'x86-core-2025-05-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (331 commits) x86/bugs: Fix spectre_v2 mitigation default on Intel x86/bugs: Restructure ITS mitigation x86/xen/msr: Fix uninitialized variable 'err' x86/msr: Remove a superfluous inclusion of x86/paravirt: Restrict PARAVIRT_XXL to 64-bit only x86/mm/64: Make 5-level paging support unconditional x86/mm/64: Make SPARSEMEM_VMEMMAP the only memory model x86/mm/64: Always use dynamic memory layout x86/bugs: Fix indentation due to ITS merge x86/cpuid: Rename hypervisor_cpuid_base()/for_each_possible_hypervisor_cpuid_base() to cpuid_base_hypervisor()/for_each_possible_cpuid_base_hypervisor() x86/cpu/intel: Rename CPUID(0x2) descriptors iterator parameter x86/cacheinfo: Rename CPUID(0x2) descriptors iterator parameter x86/cpuid: Rename cpuid_get_leaf_0x2_regs() to cpuid_leaf_0x2() x86/cpuid: Rename have_cpuid_p() to cpuid_feature() x86/cpuid: Set as the main CPUID header x86/cpuid: Move CPUID(0x2) APIs into x86/msr: Add rdmsrl_on_cpu() compatibility wrapper x86/mm: Fix kernel-doc descriptions of various pgtable methods x86/asm-offsets: Export certain 'struct cpuinfo_x86' fields for 64-bit asm use too x86/boot: Defer initialization of VM space related global variables ... List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

69cb33e2f81a3265383f0c8bbd27c32b4a5a6bf3 - Merge branch 'x86/microcode' into x86/core, to merge dependent commits

Tue, 13 May 2025 10:37:52 +0200

Merge branch 'x86/microcode' into x86/core, to merge dependent commitsPrepare to resolve conflicts with an upstream series of fixes that conflictwith pending x86 changes: 6f5bf947bab0 Merge tag 'its-for-linus-20250509' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipSigned-off-by: Ingo Molnar List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst

4e2c719782a84702db7fc2dc07ced796f308fec7 - x86/cpu: Help users notice when running old Intel microcode

Tue, 22 Apr 2025 08:32:47 +0200

x86/cpu: Help users notice when running old Intel microcodeOld microcode is bad for users and for kernel developers.For users, it exposes them to known fixed security and/or functionalissues. These obviously rarely result in instant dumpster fires inevery environment. But it is as important to keep your microcode upto date as it is to keep your kernel up to date.Old microcode also makes kernels harder to debug. A developer lookingat an oops need to consider kernel bugs, known CPU issues and unknownCPU issues as possible causes. If they know the microcode is up todate, they can mostly eliminate known CPU issues as the cause.Make it easier to tell if CPU microcode is out of date. Add a listof released microcode. If the loaded microcode is older than therelease, tell users in a place that folks can find it: /sys/devices/system/cpu/vulnerabilities/old_microcodeTell kernel kernel developers about it with the existing taintflag: TAINT_CPU_OUT_OF_SPEC== Discussion ==When a user reports a potential kernel issue, it is very commonto ask them to reproduce the issue on mainline. Running mainline,they will (independently from the distro) acquire a more up-to-datemicrocode version list. If their microcode is old, they willget a warning about the taint and kernel developers can take thatinto consideration when debugging.Just like any other entry in "vulnerabilities/", users are free tomake their own assessment of their exposure.== Microcode Revision Discussion ==The microcode versions in the table were generated from the Intelmicrocode git repo: 8ac9378a8487 ("microcode-20241112 Release")which as of this writing lags behind the latest microcode-20250211.It can be argued that the versions that the kernel picks to call "old"should be a revision or two old. Which specific version is picked isless important to me than picking *a* version and enforcing it.This repository contains only microcode versions that Intel has deemedto be OS-loadable. It is quite possible that the BIOS has loaded anewer microcode than the latest in this repo. If this happens, thesystem is considered to have new microcode, not old.Specifically, the sysfs file and taint flag answer the question: Is the CPU running on the latest OS-loadable microcode, or something even later that the BIOS loaded?In other words, Intel never publishes an authoritative list of CPUsand latest microcode revisions. Until it does, this is the best thatLinux can do.Also note that the "intel-ucode-defs.h" file is simple, ugly andhas lots of magic numbers. That's on purpose and should allow asingle file to be shared across lots of stable kernel regardless of ifthey have the new "VFM" infrastructure or not. It was generated witha dumb script.== FAQ ==Q: Does this tell me if my system is secure or insecure?A: No. It only tells you if your microcode was old when the system booted.Q: Should the kernel warn if the microcode list itself is too old?A: No. New kernels will get new microcode lists, both mainline and stable. The only way to have an old list is to be running an old kernel in which case you have bigger problems.Q: Is this for security or functional issues?A: Both.Q: If a given microcode update only has functional problems but no security issues, will it be considered old?A: Yes. All microcode image versions within a microcode release are treated identically. Intel appears to make security updates without disclosing them in the release notes. Thus, all updates are considered to be security-relevant.Q: Who runs old microcode?A: Anybody with an old distro. This happens all the time inside of Intel where there are lots of weird systems in labs that might not be getting regular distro updates and might also be running rather exotic microcode images.Q: If I update my microcode after booting will it stop saying "Vulnerable"?A: No. Just like all the other vulnerabilies, you need to reboot before the kernel will reassess your vulnerability.Signed-off-by: Dave Hansen Signed-off-by: Ingo Molnar Cc: "Ahmed S. Darwish" Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Brian Gerst Cc: John Ogness Cc: Josh Poimboeuf Cc: Juergen Gross Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Link: https://lore.kernel.org/all/20250421195659.CF426C07%40davehans-spike.ostc.intel.com(cherry picked from commit 9127865b15eb0a1bd05ad7efe29489c44394bdc1) List of files: /linux/Documentation/admin-guide/hw-vuln/old_microcode.rst