Documentation/admin-guide/hw-vuln/old_microcode.rst
Source file repositories/reference/linux-study-clean/Documentation/admin-guide/hw-vuln/old_microcode.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/admin-guide/hw-vuln/old_microcode.rst- Extension
.rst- Size
- 801 bytes
- Lines
- 22
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
=============
Old Microcode
=============
The kernel keeps a table of released microcode. Systems that had
microcode older than this at boot will say "Vulnerable". This means
that the system was vulnerable to some known CPU issue. It could be
security or functional, the kernel does not know or care.
You should update the CPU microcode to mitigate any exposure. This is
usually accomplished by updating the files in
/lib/firmware/intel-ucode/ via normal distribution updates. Intel also
distributes these files in a github repo:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.git
Just like all the other hardware vulnerabilities, exposure is
determined at boot. Runtime microcode updates do not change the status
of this vulnerability.Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.