Getting to Know Spectre & Meltdown Checker

### Overview In this talk presented at the Open Source Summit, Stéphane Lesimple (security team at OVHcloud) and Agata Gruza (performance engineer at Intel) introduce the background, inner workings, and development lifecycle of the open-source tool *Spectre & Meltdown Checker*. Started by Stéphane in early 2018 following the disclosure of speculative execution flaws, the script provides system administrators and engineers with clear assessments of whether hardware is affected by transient execution vulnerabilities and whether appropriate mitigations are active across system layers.

### Key Topics - **Evolution of Vulnerability Classes**: The presentation contrasts traditional implementation bugs (e.g., buffer overflows, race conditions fixed by simple software patches) and design flaws (e.g., BEAST attack against TLS 1.0 specifications) with hardware and speculative execution flaws. Prior to 2018, hardware flaws were thought to require physical chip access. Transient speculative execution attacks showed microarchitectural side effects could be exploited in software, impacting virtually all operating systems and software. - **Multi-Layer Mitigation Complexity**: Addressing hardware vulnerabilities cannot be achieved with single application patches. Mitigations require coordinating up to five layers: CPU microcode updates, hypervisor adjustments, OS kernel patches, VM guest kernel configurations, and user-space recompilation with updated compilers (e.g., for Spectre variant 1). - **Script Inception and Governing Principles**: Prompted by rapidly evolving vendor statements and unusual kernel events (such as late merging and silent backporting of KPTI), the script was built to answer two questions: "Is hardware affected?" and "Are mitigations in place?" Key development principles include assuming systems are vulnerable by default when information is incomplete, avoiding hardcoded kernel versions to accommodate backports, not blindly trusting `/sys` files, inspecting raw binary images/flags rather than running error-prone proof-of-concept exploits, avoiding system modifications, and maintaining POSIX shell compatibility.

### Technical Details & Implementation - **Capabilities and Demo**: The tool inspects CPU flags (e.g., `IBRS`, `IBPB`, `rdcl_no`, `md_clear`), microcode revisions, and kernel binaries. It includes an offline mode to inspect non-running kernel images, config files, and System.map files, as well as an environment-variable-driven CPU mocking mode. Microcode status is cross-referenced against embedded databases sourced from the MCExtractor project and Intel's firmware GitHub repository. - **Intel Contributor Journey**: Agata Gruza details Intel's contributions, focusing on script patches for vulnerabilities such as MDS, TAA, Enhanced IBRS, and SRBDS (Special Register Buffer Data Sampling). Contributing upstream ensures that users can assess systems on disclosure day, as script logic is integrated directly into validation and mitigation workflows. - **SRBDS Deep Dive**: Adding detection for SRBDS required parsing CPU family/models (primarily Family 6), stepping numbers, and hardware capabilities (TSX and MDS status) for specific lines like Kaby Lake and Kaby Lake L. The detection logic reads CPUID bits to verify microcode mitigation capability (bit 9), followed by reading Model-Specific Registers (specifically `MSR 0x123`) to evaluate whether the mitigation is actively enabled (value `0`) or disabled (value `1`).

### Takeaways Spectre & Meltdown Checker is strictly a read-only assessment script; it cannot install packages, update microcode, or automatically fix vulnerabilities. While newer Linux kernels offer vulnerability files in sysfs, older kernels and selective backports make dedicated inspection scripts necessary. As new speculative execution mitigations emerge, the script faces challenges in maintenance, hardcoded CPU lists, and redundant logic, highlighting the importance of continuous open-source community contributions.