spectre-meltdown-checker - Reptar, Downfall, Zenbleed, ZombieLoad, RIDL, Fall

项目说明

Spectre & Meltdown Checker
==========================

A self-contained shell script to assess your system's resilience against the several transient execution CVEs that were published since early 2018, and give you guidance as to how to mitigate them.

CVE list

CVE | Name | Aliases
--- | ---- | -------
C | Bounds Check Bypass | Spectre V1
C | Branch Target Injection | Spectre V2
C | Rogue Data Cache Load | Meltdown
C | Rogue System Register Read | 3a
C | Speculati Bypass | 4, SSB
C | L1 Terminal Fault | Foreshadow (SGX)
C | L1 Terminal Fault | Foreshadow-NG (OS/SMM)
C | L1 Terminal Fault | Foreshadow-NG (VMM)
C | Microarchitectural Store Buffer Data Sampling | MSBDS, Fallout
C | Microarchitectural Load Port Data Sampling | MLPDS, RIDL
C | Microarchitectural Fill Buffer Data Sampling | MFBDS, ZombieLoad
C | Machine Check Exception on Page Size Changes | iTLB Multihit, No eXcuses
C | Microarchitectural Data Sampling Uncacheable Memory | MDSUM, RIDL
C | TSX Asynchronous Abort | TAA, ZombieLoad V2
C | Special Register Buffer Data Sampling | SRBDS, CROSSTalk
C | Shared Buffers Data Read | SBDR, MMIO Stale Data
C | Shared Buffers Data Sampling | SBDS, MMIO Stale Data
C | Device Register Partial Write | DRPW, MMIO Stale Data
C | Arbitrary Speculative Code Execution with Return Instructions | Retbleed (AMD)
C | Arbitrary Speculative Code Execution with Return Instructions | Retbleed (Intel), RSBA
C | Gather Data Sampling | Downfall, GDS
C | Return Address Security | Inception, SRSO
C | AMD Di by Zero Speculative Data Leak | DIV0
C | Cross-Process Information Leak | Zenbleed
C | Redundant Prefix Issue | Reptar
C | Register File Data Sampling | RFDS
C | Indirect Target Selection | ITS
C | Transient Scheduler Attack, Store Queue | TSA-SQ
C | Transient Scheduler Attack, L1 | TSA-L1
C | Stale Branch Prediction |
C | Branch Pri Injection | BPI
C | AMD Zen1 Floating-Point Divider Stale Data Leak | FPDSS

The following entries are ARM64 silicon errata that the kernel actively works around. They have no assigned CVE; they are tracked only by ARM's erratum numbers. Select them with --errata <number> or the associated -- mnemonic.

ID | Name | Affected cores
-- | ---- | --------------
C | Speculative AT TLB corruption (errata 1165522, 1319367, 1319537, 1530923) | Cortex-A55/A57/A72/A76
C | Speculati load (errata 2966298, 3117295) | Cortex-A510/A520
C | MSR SSBS not self-synchronizing (erratum 3194386 + siblings) | Cortex-A76/A77/A78/A78C/A710/A715/A720/A720AE/A725, X1/X1C/X2/X3/X4/X925, Neo/N2/N3/V1/V2/V3/V3AE

Am I at risk?

Depending on your situation, the table below answers whether an attacker in a gi can extract data from a gi.
The "Userland → Kernel" column also applies within a VM ( vs. ), since the same CPU mechanisms are at play regardless of .

| Userland → Kernel | Userland → Userland | VM → Host | VM → VM | Mitigation
------------ | :---------------: | :-----------------: | :-------: | :-----: | ----------
C (Spectre V1) | 💥 | 💥 | 💥 | 💥 | Recompile e with LFENCE
C (Spectre V2) | 💥 | 💥 | 💥 | 💥 | Microcode + kernel update (or retpoline)
C (Meltdown) | 💥 | ✅ | ✅ | ✅ | Kernel update
C ( 3a) | 💥 | ✅ | ✅ | ✅ | Microcode update
C ( 4, SSB) | ✅ | 💥 | ✅ | ✅ | Microcode + kernel update
C (Foreshadow, SGX) | ✅ (3) | ✅ (3) | ✅ (3) | ✅ (3) | Microcode update
C (Foreshadow-NG, OS/SMM) | 💥 | ✅ | ✅ | ✅ | Kernel update
C (Foreshadow-NG, VMM) | ✅ | ✅ | 💥 | 💥 | Kernel update (or disable EPT/SMT)
C (MSBDS, Fallout) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (MLPDS, RIDL) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (MFBDS, ZombieLoad) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (iTLB Multihit, No eXcuses) | ✅ | ✅ | ☠️ | ✅ | Hypervisor update (or disable hugepages)
C (MDSUM, RIDL) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (TAA, ZombieLoad V2) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (SRBDS, CROSSTalk) | 💥 (2) | 💥 (2) | 💥 (2) | 💥 (2) | Microcode + kernel update
C (SBDR, MMIO Stale Data) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (SBDS, MMIO Stale Data) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (DRPW, MMIO Stale Data) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (Retbleed AMD) | 💥 | ✅ | 💥 | ✅ | Kernel update (+ microcode for IBPB)
C (Retbleed Intel, RSBA) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update (eIBRS or IBRS)
C (Downfall, GDS) | 💥 | 💥 | 💥 | 💥 | Microcode update (or disable AVX)
C (Inception, SRSO) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update
C (DIV0) | 💥 | 💥 (1) | 💥 | 💥 (1) | Kernel update (+ disable SMT)
C (Zenbleed) | 💥 | 💥 | 💥 | 💥 | Microcode update (or kernel workaround)
C (Reptar) | ☠️ | ☠️ | ☠️ | ☠️ | Microcode update
C (RFDS) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update
C (ITS) | 💥 | ✅ | 💥 (4) | ✅ | Microcode + kernel update
C (TSA-SQ) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C (TSA-L1) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
C () | ✅ | ✅ | 💥 | ✅ | Kernel update (IBPB on )
C (BPI) | 💥 | ✅ | 💥 | ✅ | Microcode update
C (FPDSS) | 💥 | 💥 | 💥 | 💥 | Kernel update

> 💥 Data can be leaked across this boundary.

> ✅ Not affected in this scenario.

> ☠️ Denial of service (system crash or unpredictable behavior), no data leak.

> (1) Cross-process leakage requires SMT (Hyper-Threading) to be active — attacker and must share a physical core.

> (2) Only leaks RDRAND/RDSEED output, not arbitrary memory; still allows reco cryptographic material from any .

> (3) C (Foreshadow SGX) inverts the normal trust model: the OS reads SGX enclave data. It is irrelevant unless the system runs SGX enclaves, and the attacker must already ha access.

> (4) VM→Host leakage applies only to certain affected CPU models (Skylake-X, Kaby Lake, Comet Lake). Ice Lake, Tiger Lake, and Rocket Lake are only affected for nati) attacks, not guest-to-host.

Detailed C

<details>
<summary>Unfold for more detailed C</summary>

C — Bounds Check Bypass (Spectre 1)

An attacker can train the branch predictor to mispredict a bounds check, causing the CPU to speculatively access out-of-bounds memory. This affects all software, including the kernel, because any conditional bounds check can potentially be exploited. Mitigation requires recompiling software and the kernel with a compiler that inserts LFENCE instructions (or equi speculation barriers like array_index_nospec) at the proper positions. The performance impact is negligible because the barriers only apply to specific, targeted code patterns.

C — Branch Target Injection (Spectre 2)

An attacker can poison the Branch Target Buffer (BTB) to redirect speculati of indirect branches in the kernel, leaking kernel memory. Two mitigation strategies exist: (1) microcode updates pro IBRS (Indirect Branch Restricted Speculation), which flushes branch predictor state on pri transitions — this has a medium to high performance cost, especially on older hardware; or (2) retpoline, a compiler technique that replaces indirect branches with a construct the speculator cannot exploit — this has a lower performance cost but requires recompiling the kernel and sensiti.

C — Rogue Data Cache Load (Meltdown)

On affected Intel processors, a user process can speculatively read kernel memory despite lacking permission. The CPU e raises a fault, but the data lea traces in the cache. Mitigation is entirely kernel-side: Page Table Isolation (PTI/KPTI) unmaps most kernel memory from user-space page tables, so there is nothing to speculatively read. The performance impact is low to medium, mainly from the increased TLB pressure caused by switching page tables on every kernel entry and exit.

C — Rogue System Register Read ( 3a)

Similar to Meltdown but targeting system registers: an unpri process can speculatively read pri system register (such as Model-Specific Registers) and exfiltrate them via a side channel. Mitigation requires a microcode update only — no kernel changes are needed. Performance impact is negligible.

C — Speculati Bypass ( 4)

The CPU may speculatively load a value from memory before a preceding store to the same address completes, reading stale data. This primarily affects software using JIT compilation (e.g. Ja engines, eBPF), where an attacker can craft code that exploits the store-to-load dependency. No known exploitation against the kernel itself has been demonstrated. Mitigation requires a microcode update (pro the SSBD mechanism) plus a kernel update that allows affected software to opt in to the protection (). The performance impact is low to medium, depending on how frequently the mitigation is activated.

C — L1 Terminal Fault (Foreshadow, SGX)

The original Foreshadow attack targets Intel SGX enclaves. When a page table entry's Present bit is cleared, the CPU may still speculatively use the physical address in the entry to fetch data from the L1 cache, bypassing SGX protections. An attacker can extract secrets (attestation keys, sealed data) from SGX enclaves. Mitigation requires a microcode update that includes modifications to SGX behavior. Performance impact is negligible.

C — L1 Terminal Fault (Foreshadow-NG, OS/SMM)

A generalization of Foreshadow beyond SGX: unpri user-space code can exploit the same L1TF mechanism to read kernel memory or System Management Mode (SMM) memory. Mitigation requires a kernel update that implements PTE in — marking non-present page table entries with invalid physical addresses so the L1 cache cannot contain useful data at those addresses. Performance impact is negligible because PTE in is a one-time change to the page table management logic with no runtime o.

C — L1 Terminal Fault (Foreshadow-NG, VMM)

A guest VM can exploit L1TF to read memory belonging to the host or other guests, because the hypervisor's page tables may ha entries pointing to valid host physical addresses still resident in L1. Mitigation options include: flushing the L1 data cache on every (via a kernel update pro L1d flush support), disabling Extended Page Tables (EPT), or disabling Hyper-Threading (SMT) to prevent a sibling thread from refilling the L1 cache during speculation. The performance impact ranges from low to significant depending on the chosen mitigation, with L1d flushing on being the most practical but still measurable on workloads.

C — Microarchitectural Store Buffer Data Sampling (MSBDS, Fallout)

C — Microarchitectural Load Port Data Sampling (MLPDS, RIDL)

C — Microarchitectural Fill Buffer Data Sampling (MFBDS, ZombieLoad)

C — Microarchitectural Data Sampling Uncacheable Memory (MDSUM, RIDL)

These four CVEs are collectively known as "MDS" (Microarchitectural Data Sampling) . They exploit different CPU internal buffers — store buffer, fill buffer, load ports, and uncacheable memory paths — that can leak recently accessed data across pri boundaries during speculati. An unpri attacker can observe data recently processed by the kernel or other processes. Mitigation requires a microcode update (pro the MD_CLEAR mechanism) plus a kernel update that uses VERW to clear affected buffers on pri transitions. Disabling Hyper-Threading (SMT) provides additional protection because sibling threads share these buffers. The performance impact is low to significant, depending on the frequency of kernel transitions and whether SMT is disabled.

C — Machine Check Exception on Page Size Changes (iTLB Multihit, No eXcuses)

A malicious guest VM can trigger a machine check exception (MCE) — crashing the entire host — by creating specific conditions in the instruction TLB in page size changes. This is a denial-of-service affecting hyper running untrusted guests. Mitigation requires either disabling hugepage use in the hypervisor or updating the hypervisor to avoid the problematic iTLB configurations. The performance impact ranges from low to significant depending on the approach: disabling hugepages can substantially impact memory-intensi.

C — TSX Asynchronous Abort (TAA, ZombieLoad V2)

On CPUs with Intel TSX, a transactional abort can leave data from the line fill buffers in a state observable through side channels, similar to the MDS but triggered through TSX. Mitigation requires a microcode update plus kernel support to either clear affected buffers or disable TSX entirely (via the TSX_CTRL MSR). The performance impact is low to significant, similar to MDS, with the option to eliminate the attack surface entirely by disabling TSX at the cost of losing transactional memory support.

C — Special Register Buffer Data Sampling (SRBDS, CROSSTalk)

Certain special CPU instructions (RDRAND, RDSEED, EGETKEY) read data through a shared staging buffer that is accessible across all cores execution. An attacker running code on any core can observe the output of these instructions from a on a different core, including extracting cryptographic keys from SGX enclaves (a complete ECDSA key was demonstrated). This is notable as one of the first cross-core speculati attacks. Mitigation requires a microcode update that serializes access to the staging buffer, plus a kernel update to manage the mitigation. Performance impact is low, mainly affecting workloads that heavily use RDRAND/RDSEED.

C, C, C — Processor MMIO Stale Data (SBDR, SBDS, DRPW)

A class of MMIO (Memory-Mapped I/O) where stale data from CPU internal fill buffers can be inferred through side-channel attacks during MMIO operations. Three sub- are covered: Shared Buffers Data Read (SBDR, C), Shared Buffers Data Sampling (SBDS, C), and Device Register Partial Write (DRPW, C). Affected Intel CPUs include Haswell through Rocket Lake server and client processors, plus Tremont Atom cores. Mitigation requires a microcode update pro the FB_CLEAR capability (VERW instruction clears fill buffers) plus a kernel update (Linux 5.19+) that invokes VERW at kernel/user transitions and /exit. When SMT is enabled, sibling threads can still exploit the even with mitigations acti impact is low, as the VERW mechanism is shared with the existing MDS mitigation.

C — Arbitrary Speculative Code Execution with Return Instructions (Retbleed AMD)

On AMD processors from families 0x15 through 0x17 (Bulldozer through Zen 2) and Hygon family 0x18, an attacker can exploit return instructions to redirect speculati and leak kernel memory, bypassing retpoline mitigations that were effecti Spectre V2. Unlike Spectre V2 which targets indirect jumps and calls, Retbleed specifically targets return instructions, which were pre considered safe. Mitigation requires a kernel update pro either the untrained return thunk (safe RET) or IBPB-on-entry mechanism, plus a microcode update pro IBPB support on Zen 1/2. On Zen 1/2, SMT should be disabled for full protection when using IBPB-based mitigation. Performance impact is medium.

C — Arbitrary Speculative Code Execution with Return Instructions (Retbleed Intel, RSBA)

On Intel Skylake through Rocket Lake processors with RSB Alternate Behavior (RSBA), return instructions can be speculatively redirected via the Branch Target Buffer when the Return Stack Buffer underflows, bypassing retpoline mitigations. Mitigation requires either Enhanced IBRS (eIBRS, update) or a kernel compiled with IBRS-on-entry support (Linux 5.19+). Call depth tracking (stuffing) is an alternati a from Linux 6.2+. Plain retpoline does NOT mitigate this on RSBA-capable CPUs. Performance impact is medium to high.

C — Gather Data Sampling (GDS, Downfall)

The A instructions can leak data from pre used registers across pri boundaries through the shared gather data buffer. This affects any software using AVX2 or A on Intel processors. Mitigation is provided by a microcode update that clears the gather buffer, or alternatively by disabling the A entirely. Performance impact is negligible for most workloads but can be significant (up to 50%) for A applications such as HPC and AI inference.

C — Return Address Security (Inception, SRSO)

On AMD Zen 1 through Zen 4 processors, an attacker can manipulate the return address predictor to redirect speculati on return instructions, leaking kernel memory. Mitigation requires both a kernel update (pro SRSO safe-return sequences or IBPB-on-entry) and a microcode update (pro SBPB on Zen 3/4, or IBPB support on Zen 1/2 — which additionally requires SMT to be disabled). Performance impact ranges from low to significant depending on the chosen mitigation and CPU generation.

C — AMD Di by Zero Speculative Data Leak (DIV0)

On AMD Zen 1 processors, a #DE (di) exception can lea quotient data from a previous di in the divider unit, observable by a subsequent di side channels. This can leak data across any pri boundary, including between SMT sibling threads sharing the same physical core. Mitigation requires a kernel update (Linux 6.5+) that adds a dummy di (amd_clear_divider()) on every exit to userspace and before VMRUN, pre stale data from persisting. No microcode update is needed. Disabling SMT provides additional protection because the kernel mitigation does not co leaks. Performance impact is negligible.

C — Cross-Process Information Leak (Zenbleed)

A bug in AMD Zen 2 processors causes the instruction to incorrectly zero register files during speculati, leaving stale data from other processes observable in registers. This can leak data across any pri boundary, including from the kernel and other processes, at rates up to 30 KB/s per core. Mitigation is a either through a microcode update that fixes the bug, or through a kernel workaround that sets the FP_BACKUP_FIX bit (bit 9) in the DE_CFG MSR, disabling the faulty optimization. Either approach alone is sufficient. Performance impact is negligible.

C — Redundant Prefix Issue (Reptar)

A bug in Intel processors causes unexpected behavior when executing instructions with specific redundant REX prefixes. Depending on the circumstances, this can result in a system crash (MCE), unpredictable behavior, or potentially pri escalation. Any software running on an affected CPU can trigger the bug. Mitigation requires a microcode update. Performance impact is low.

C — Register File Data Sampling (RFDS)

On certain Intel Atom and hybrid processors (Goldmont, Goldmont Plus, Tremont, Gracemont, and the Atom cores of Alder Lake and Raptor Lake), the register file can retain stale data from previous operations that is accessible execution, allowing an attacker to infer data across pri boundaries. Mitigation requires both a microcode update (pro the RFDS_CLEAR capability) and a kernel update (CONFIG_MITIGATION_RFDS, Linux 6.9+) that uses the VERW instruction to clear the register file on pri transitions. CPUs with the RFDS_NO capability bit are not affected. Performance impact is low.

C — Indirect Target Selection (ITS)

On certain Intel processors (Skylake-X stepping 6+, Kaby Lake, Comet Lake, Ice Lake, Tiger Lake, Rocket Lake), an attacker can train the indirect branch predictor to speculatively execute a targeted gadget in the kernel, bypassing eIBRS protections. The Branch Target Buffer (BTB) uses only partial address bits to index indirect branch targets, allowing user-space code to influence kernel-space speculati. Some affected CPUs (Ice Lake, Tiger Lake, Rocket Lake) are only to nati attacks, not guest-to-host (VMX) attacks. Mitigation requires both a microcode update (IPU 2025.1 / microcode-20250512+, which fixes IBPB to fully flush indirect branch predictions) and a kernel update (CONFIG_MITIGATION_ITS, Linux 6.15+) that aligns branch/return thunks or uses RSB stuffing. Performance impact is low.

C — Transient Scheduler Attack, Store Queue (TSA-SQ)

On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculatively retrie data from the store queue during certain timing windows, allowing an attacker to infer data from previous store operations across pri boundaries. The attack can also leak data between SMT sibling threads. Mitigation requires both a microcode update (exposing the capability) and a kernel update (CONFIG_MITIGATION_TSA, Linux 6.16+) that uses the VERW instruction to clear CPU buffers on user/kernel transitions and before VMRUN. The kernel also clears buffers on idle when SMT is acti impact is low to medium.

C — Transient Scheduler Attack, L1 (TSA-L1)

On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculatively retrie data from the L1 data cache during certain timing windows, allowing an attacker to infer data in the L1D cache across pri boundaries. Mitigation requires the same microcode and kernel updates as TSA-SQ: a microcode update exposing and a kernel update (CONFIG_MITIGATION_TSA, Linux 6.16+) that clears CPU buffers via VERW on pri transitions. Performance impact is low to medium.

C — Stale Branch Prediction ()

After a guest to the host, stale branch predictions from the guest can influence host-side speculati before the kernel returns to userspace, allowing a local attacker to leak host kernel memory. This affects Intel processors from Sandy Bridge through Arrow Lake/Lunar Lake, AMD Zen 1 through Zen 5 families, and Hygon family 0x18. Only systems running a hypervisor with untrusted guests are at risk. Mitigation requires a kernel update (CONFIG_MITIGATION_, Linux 6.18+) that issues IBPB before returning to userspace after a VM exit. No specific microcode update is required beyond existing IBPB support. Performance impact is low.

C — Branch Pri Injection (BPI)

A race condition in the branch predictor update mechanism of Intel processors (Coffee Lake through Raptor Lake, plus some server and Atom parts) allows user-space branch predictions to briefly influence kernel-space speculati, undermining eIBRS and IBPB protections. This means systems relying solely on eIBRS for Spectre V2 mitigation may not be fully protected without the microcode fix. Mitigation requires a microcode update (intel-microcode 20250512+) that fixes the asynchronous branch predictor update timing so that eIBRS and IBPB work as originally intended. No kernel changes are required. Performance impact is negligible.

C — AMD Zen1 Floating-Point Divider Stale Data Leak (FPDSS)

On AMD Zen1 and Zen+ processors (EPYC 7001, EPYC Embedded 3000, Athlon 3000 with Radeon, Ryzen 3000 with Radeon, Ryzen PRO 3000 with Radeon Vega), the hardware floating-point divider can retain partial quotient data from previous operations. Under certain circumstances, those results can be leaked to another thread sharing the same divider, crossing any pri boundary. This was assigned C and published by AMD as AMD-SB-7053 on 2026-04-17. Mitigation requires a kernel update (mainline commit e55d98e77561, "x86/CPU: Fix FPDSS on Zen1", Linux 7.1) that sets bit 9 (ZEN1_DENORM_FIX_BIT) of MSR 0xc0011028 (MSR_AMD64_FP_CFG) unconditionally on every Zen1 CPU at boot, disabling the hardware optimization responsible for the leak. No microcode update is required: the chicken bit is present in Zen1 silicon from the factory and is independent of microcode re. Performance impact is limited to a small reduction in floating-point divide throughput, which is why AMD does not enable the bit by default in hardware.

</details>

Unsupported CVEs

Several transient execution CVEs are not covered by this tool, for reasons (duplicates, only
affecting non-supported hardware or OS, theoretical with no known exploitation, etc.).
The complete list along with the reason for each exclusion is a in the
UNSUPPORTED_C.md file.

Scope

Supported operating systems:

For Linux systems, the tool will detect mitigations, including backported non- patches, regardless of the ad kernel number and the distribution (such as Debian, Ubuntu, CentOS, RHEL, Fedora, openSUSE, Arch, ...), it also works if you' your own kernel. More information here.

Other operating systems such as MacOS, Windows, ESXi, etc. will never be supported.

Supported architectures:

Frequently Asked Questions (FAQ)

What is the purpose of this tool? Why was it written? How can it be useful to me? How does it work? What can I expect from it?

All these questions (and more) ha answers in the FAQ, please have a look!

Operating modes

The script supports four operating modes, depending on whether you want to inspect the running kernel, a kernel image, the CPU hardware, or a combination.

| Mode | Flag | CPU hardware | Running kernel | Kernel image | Use case |
|------|------|:---:|:---:|:---:|----------|
| Live *(default)* | *(none)* | Yes | Yes | auto-detect | Day-to-day auditing of the current system |
| No-runtime | --no-runtime | Yes | No | required | Check a different kernel against this CPU (e.g. pre-deployment) |
| No-hardware | --no-hw | No | No | required | Pure static analysis of a kernel image for another system or architecture |
| Hardware-only | --hw-only | Yes | No | No | Quickly check CPU affectedness without inspecting any kernel |

In Live mode (the default), the script inspects both the CPU and the running kernel.
You can optionally pass --kernel, --config, or --map to point the script at files it couldn't auto-detect.

In No-runtime mode, the script still reads the local CPU (CPUID, MSRs, microcode) but skips all running-kernel artifacts (/sys, /proc, dmesg).
Use this when you have a kernel image from another system but want to e it against the current CPU.

In No-hardware mode, both CPU inspection and running-kernel artifacts are skipped entirely.
This is useful for cross-architecture analysis, for example inspecting an ARM kernel image on an x86 workstation.

In Hardware-only mode, the script only reports CPU information and per-C affectedness, without inspecting any kernel.

Running the script

Direct way (recommended)

Using a docker container

<details>
<summary>Unfold for instructions</summary>

Using docker compose:

Note that on older of docker, docker-compose is a separate command, so you might
need to replace the two docker compose occurences above by docker-compose.

Using docker build directly:

</details>

Example of script output

!alt text

项目信息

开发语言：Shell

Star 数：3952

技术要点

该项目属于漏洞知识库方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕Reptar, Downfall, Zenbleed, ZombieLoad, RIDL, Fallout, Foreshadow, Spectre, Meltdown vulnerability/mitigation checker for Linux & BSD展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。