chore: don't include src/ generated files in build

built from commit a77cf8264f
 dated 2026-04-02 23:49:40 +0200
 by Stéphane Lesimple (speed47_github@speed47.net)

.github/workflows/autoupdate.yml

@@ -0,0 +1,36 @@
+name: autoupdate
+
+on:
+  workflow_dispatch:
+  schedule:
+    - cron: '42 9 * * *'
+
+permissions:
+  pull-requests: write
+
+jobs:
+  autoupdate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install prerequisites
+        run: sudo apt-get update && sudo apt-get install -y --no-install-recommends iucode-tool sqlite3 unzip
+      - name: Update microcode versions
+        run: ./spectre-meltdown-checker.sh --update-builtin-fwdb
+      - name: Check git diff
+        id: diff
+        run: |
+          echo change="$(git diff spectre-meltdown-checker.sh | awk '/MCEDB/ { if(V) { print V" to "$4; exit } else { V=$4 } }')" >> "$GITHUB_OUTPUT"
+          echo nbdiff="$(git diff spectre-meltdown-checker.sh | grep -cE -- '^\+# [AI],')" >> "$GITHUB_OUTPUT"
+          git diff
+          cat "$GITHUB_OUTPUT"
+      - name: Create Pull Request if needed
+        if: steps.diff.outputs.nbdiff != '0'
+        uses: peter-evans/create-pull-request@v7
+        with:
+          branch: autoupdate-fwdb
+          commit-message: "update: fwdb from ${{ steps.diff.outputs.change }}, ${{ steps.diff.outputs.nbdiff }} microcode changes"
+          title: "[Auto] Update fwdb from ${{ steps.diff.outputs.change }}"
+          body: |
+            Automated PR to update fwdb from ${{ steps.diff.outputs.change }}
+            Detected ${{ steps.diff.outputs.nbdiff }} microcode changes

.github/workflows/build.yml

@@ -0,0 +1,114 @@
+name: build
+
+on:
+  push:
+    branches:
+      - test
+      - source
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v6
+      with:
+        persist-credentials: true
+    - name: install prerequisites
+      run: sudo apt-get update && sudo apt-get install -y shellcheck shfmt jq sqlite3 iucode-tool make
+    - name: update Intel model list
+      run: ./scripts/update_intel_models.sh
+    - name: build and check
+      run: |
+        make build fmt-check shellcheck
+        mv spectre-meltdown-checker.sh dist/
+    - name: check direct execution
+      run: |
+        expected=$(cat .github/workflows/expected_cve_count)
+        cd dist
+        nb=$(sudo ./spectre-meltdown-checker.sh --batch json | jq '.[]|.CVE' | wc -l)
+        if [ "$nb" -ne "$expected" ]; then
+          echo "Invalid number of CVEs reported: $nb instead of $expected"
+          exit 1
+        else
+          echo "OK $nb CVEs reported"
+        fi
+    - name: check docker compose run execution
+      run: |
+        expected=$(cat .github/workflows/expected_cve_count)
+        cd dist
+        docker compose build
+        nb=$(docker compose run --rm spectre-meltdown-checker --batch json | jq '.[]|.CVE' | wc -l)
+        if [ "$nb" -ne "$expected" ]; then
+          echo "Invalid number of CVEs reported: $nb instead of $expected"
+          exit 1
+        else
+          echo "OK $nb CVEs reported"
+        fi
+    - name: check docker run execution
+      run: |
+        expected=$(cat .github/workflows/expected_cve_count)
+        cd dist
+        docker build -t spectre-meltdown-checker .
+        nb=$(docker run --rm --privileged -v /boot:/boot:ro -v /dev/cpu:/dev/cpu:ro -v /lib/modules:/lib/modules:ro spectre-meltdown-checker --batch json | jq '.[]|.CVE' | wc -l)
+        if [ "$nb" -ne "$expected" ]; then
+          echo "Invalid number of CVEs reported: $nb instead of $expected"
+          exit 1
+        else
+          echo "OK $nb CVEs reported"
+        fi
+    - name: check fwdb update (separated)
+      run: |
+        cd dist
+        nbtmp1=$(find /tmp 2>/dev/null | wc -l)
+        ./spectre-meltdown-checker.sh --update-fwdb; ret=$?
+        if [ "$ret" != 0 ]; then
+          echo "Non-zero return value: $ret"
+          exit 1
+        fi
+        nbtmp2=$(find /tmp 2>/dev/null | wc -l)
+        if [ "$nbtmp1" != "$nbtmp2" ]; then
+          echo "Left temporary files!"
+          exit 1
+        fi
+        if ! [ -e ~/.mcedb ]; then
+          echo "No .mcedb file found after updating fwdb"
+          exit 1
+        fi
+    - name: check fwdb update (builtin)
+      run: |
+        cd dist
+        nbtmp1=$(find /tmp 2>/dev/null | wc -l)
+        ./spectre-meltdown-checker.sh --update-builtin-fwdb; ret=$?
+        if [ "$ret" != 0 ]; then
+          echo "Non-zero return value: $ret"
+          exit 1
+        fi
+        nbtmp2=$(find /tmp 2>/dev/null | wc -l)
+        if [ "$nbtmp1" != "$nbtmp2" ]; then
+          echo "Left temporary files!"
+          exit 1
+        fi
+    - name: create a pull request to ${{ github.ref_name }}-build
+      run: |
+        tmpdir=$(mktemp -d)
+        mv ./dist/* .github $tmpdir/
+        rm -rf ./dist
+        git fetch origin ${{ github.ref_name }}-build
+        git checkout -f ${{ github.ref_name }}-build
+        mv $tmpdir/* .
+        rm -rf src/
+        mkdir -p .github
+        rsync -vaP --delete $tmpdir/.github/ .github/
+        git add --all
+        echo =#=#= DIFF CACHED
+        git diff --cached
+        echo =#=#= STATUS
+        git status
+        echo =#=#= COMMIT
+        git config --global user.name "github-actions[bot]"
+        git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"
+        git log ${{ github.ref }} -1 --format=format:'%s%n%n built from commit %H%n dated %ai%n by %an (%ae)%n%n %b'
+        git log ${{ github.ref }} -1 --format=format:'%s%n%n built from commit %H%n dated %ai%n by %an (%ae)%n%n %b' | git commit -F -
+        git push

.github/workflows/check.yml

@@ -1,73 +0,0 @@
-name: CI
-
-on: [push, pull_request]
-
-jobs:
-  build:
-
-    runs-on: ubuntu-latest
-
-    steps:
-    - uses: actions/checkout@v1
-    - name: install prerequisites
-      run: sudo apt-get update && sudo apt-get install -y shellcheck jq sqlite3 iucode-tool
-    - name: shellcheck
-      run: shellcheck -s sh spectre-meltdown-checker.sh
-    - name: check indentation
-      run: |
-        if [ $(grep -cPv "^\t*\S|^$" spectre-meltdown-checker.sh) != 0 ]; then
-          echo "Badly indented lines found:"
-          grep -nPv "^\t*\S|^$" spectre-meltdown-checker.sh
-          exit 1
-        else
-          echo "Indentation seems correct."
-        fi
-    - name: check direct execution
-      run: |
-        expected=15
-        nb=$(sudo ./spectre-meltdown-checker.sh --batch json | jq '.[]|.CVE' | wc -l)
-        if [ "$nb" -ne "$expected" ]; then
-          echo "Invalid number of CVEs reported: $nb instead of $expected"
-          exit 1
-        else
-          echo "OK $nb CVEs reported"
-        fi
-    - name: check docker-compose run execution
-      run: |
-        expected=15
-        docker-compose build
-        nb=$(docker-compose run --rm spectre-meltdown-checker --batch json | jq '.[]|.CVE' | wc -l)
-        if [ "$nb" -ne "$expected" ]; then
-          echo "Invalid number of CVEs reported: $nb instead of $expected"
-          exit 1
-        else
-          echo "OK $nb CVEs reported"
-        fi
-    - name: check docker run execution
-      run: |
-        expected=15
-        docker build -t spectre-meltdown-checker .
-        nb=$(docker run --rm --privileged -v /boot:/boot:ro -v /dev/cpu:/dev/cpu:ro -v /lib/modules:/lib/modules:ro spectre-meltdown-checker --batch json | jq '.[]|.CVE' | wc -l)
-        if [ "$nb" -ne "$expected" ]; then
-          echo "Invalid number of CVEs reported: $nb instead of $expected"
-          exit 1
-        else
-          echo "OK $nb CVEs reported"
-        fi
-    - name: check fwdb update
-      run: |
-        nbtmp1=$(find /tmp 2>/dev/null | wc -l)
-        ./spectre-meltdown-checker.sh --update-fwdb; ret=$?
-        if [ "$ret" != 0 ]; then
-          echo "Non-zero return value: $ret"
-          exit 1
-        fi
-        nbtmp2=$(find /tmp 2>/dev/null | wc -l)
-        if [ "$nbtmp1" != "$nbtmp2" ]; then
-          echo "Left temporary files!"
-          exit 1
-        fi
-        if ! [ -e ~/.mcedb ]; then
-          echo "No .mcedb file found after updating fwdb"
-          exit 1
-        fi

.github/workflows/expected_cve_count

@@ -0,0 +1 @@
+23

.github/workflows/stale.yml

@@ -0,0 +1,33 @@
+name: 'Manage stale issues and PRs'
+
+on:
+  schedule:
+    - cron: '37 7 * * *'
+  workflow_dispatch:
+    inputs:
+      action:
+        description: "dry-run"
+        required: true
+        default: "dryrun"
+        type: choice
+        options:
+          - dryrun
+          - apply
+
+permissions:
+  issues: write
+  pull-requests: write
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/stale@v10
+        with:
+          any-of-labels: 'needs-more-info,answered'
+          labels-to-remove-when-unstale: 'needs-more-info,answered'
+          days-before-stale: 30
+          days-before-close: 7
+          stale-issue-label: stale
+          remove-stale-when-updated: true
+          debug-only: ${{ case(inputs.action == 'apply', false, true) }}

Dockerfile

@@ -1,7 +1,7 @@
-FROM alpine:3.7
+FROM alpine:latest
 
-RUN apk --update --no-cache add kmod binutils grep perl
+RUN apk --update --no-cache add kmod binutils grep perl zstd wget sharutils unzip sqlite procps coreutils iucode-tool gzip xz bzip2 lz4
 
-COPY . /check
+COPY spectre-meltdown-checker.sh /
 
-ENTRYPOINT ["/check/spectre-meltdown-checker.sh"]
+ENTRYPOINT ["/spectre-meltdown-checker.sh"]

FAQ.md

@@ -45,9 +45,9 @@ Software vulnerability:
 
 Hardware vulnerability:
 - Can be fixed? No, only mitigated (or buy new hardware!)
-- How to ~~fix~~ mitigate? In the worst case scenario, 5 "layers" need to be updated: the microcode/firmware, the host OS kernel, the hypervisor, the VM OS kernel, and possibly all the software running on the VM.
+- How to ~~fix~~ mitigate? In the worst case scenario, 5 "layers" need to be updated: the microcode/firmware, the host OS kernel, the hypervisor, the VM OS kernel, and possibly all the software running on the machine. Sometimes only a subset of those layers need to be updated. In yet other cases, there can be several possible mitigations for the same vulnerability, implying different layers. Yes, it can get horribly complicated.
 
-A more detailed video explanation is available here: https://youtu.be/2gB9U1EcCss?t=85
+A more detailed video explanation is available here: https://youtu.be/2gB9U1EcCss?t=425
 
 ## What do "affected", "vulnerable" and "mitigated" mean exactly?
 
@@ -75,7 +75,7 @@ There are a few rules that govern how this tool is written.
 
 A lot as changed since 2018. Nowadays, the industry adapted and this range of vulnerabilities is almost "business as usual", as software vulnerabilities are. However, due to their complexity, it's still not as easy as just checking a version number to ensure a vulnerability is closed.
 
-Granted, we now have a standard way under Linux to check whether our system is affected, vulnerable, mitigated against most of these vulnerabilities. By having a look at the `sysfs` hierarchy, and more precisely the `/sys/devices/system/cpu/vulnerabilities/` folder, one can have a pretty good insight about its system state for each of the listed vulnerabilities. Note that the output can be a little different with some vendors (e.g. Red Hat has some slightly different output than the vanilla kernel for some vulnerabilities), but it's still a gigantic leap forward, given where we were in 2018 when this script was started, and it's very good news. The kernel is the proper place to have this because the kernel knows everything about itself (the mitigations it might have), and the CPU (its model, and microcode features that are exposed).
+Granted, we now have a standard way under Linux to check whether our system is affected, vulnerable, mitigated against most of these vulnerabilities. By having a look at the `sysfs` hierarchy, and more precisely the `/sys/devices/system/cpu/vulnerabilities/` folder, one can have a pretty good insight about its system state for each of the listed vulnerabilities. Note that the output can be a little different with some vendors (e.g. Red Hat has some slightly different output than the vanilla kernel for some vulnerabilities), but it's still a gigantic leap forward, given where we were in 2018 when this script was started, and it's very good news. The kernel is the proper place to have this because the kernel knows everything about itself (the mitigations it might have), and the CPU (its model, and microcode features that are exposed). Note however that some vulnerabilities are not reported through this file hierarchy at all, such as Zenbleed.
 
 However I see a few reasons why this script might still be useful to you, and that's why its development has not halted when the `sysfs` hierarchy came out:
 
@@ -109,12 +109,14 @@ This tool only supports Linux, and [some flavors of BSD](#which-bsd-oses-are-sup
 
 ## The tool says there is an updated microcode for my CPU, but I don't have it!
 
-Even if your operating system is fully up to date, the tool might still tell you that there is a more recent microcode version for your CPU. Currently, it uses (and merges) information from two sources:
+Even if your operating system is fully up to date, the tool might still tell you that there is a more recent microcode version for your CPU. Currently, it uses (and merges) information from 4 sources:
 
 - The official [Intel microcode repository](https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files)
 - The awesome platomav's [MCExtractor database](https://github.com/platomav/MCExtractor) for non-Intel CPUs
+- The official [linux-firmware](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git) repository for AMD
+- Specific Linux kernel commits that sometimes hardcode microcode versions, such as for [Zenbleed](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=522b1d69219d8f083173819fde04f994aa051a98) or for the bad [Spectre](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/cpu/intel.c#n141) microcodes
 
-Generally, for Intel CPUs it means that Intel does have a more recent version for your CPU, and for other CPUs it means that a more recent version has already been seen in the wild. However, your OS vendor might have chosen not to ship this new version (yet), maybe because it's currently being tested, or for other reasons. This tool can't tell you when or if this will be the case. You should ask your vendor about it. Technically, you can still go and upgrade your microcode yourself, and use this tool to confirm whether you did it successfully. Updating the microcode for you is out of the scope of this tool, as this would violate [rule 1b](#what-are-the-main-design-decisions-regarding-this-script).
+Generally, it means a more recent version of the microcode has been seen in the wild. However, fully public availability of this microcode might be limited yet, or your OS vendor might have chosen not to ship this new version (yet), maybe because it's currently being tested, or for other reasons. This tool can't tell you when or if this will be the case. You should ask your vendor about it. Technically, you can still go and upgrade your microcode yourself, and use this tool to confirm whether you did it successfully. Updating the microcode for you is out of the scope of this tool, as this would violate [rule 1b](#what-are-the-main-design-decisions-regarding-this-script).
 
 ## The tool says that I need a more up-to-date microcode, but I have the more recent version!
 

README.md

@@ -1,25 +1,180 @@
 Spectre & Meltdown Checker
 ==========================
 
-A shell script to assess your system's resilience against the several [transient execution](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability) CVEs that were published since early 2018, and give you guidance as to how to mitigate them.
+A self-contained shell script to assess your system's resilience against the several [transient execution](https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability) CVEs that were published since early 2018, and give you guidance as to how to mitigate them.
 
-CVE                                                                             | Name                                                | Aliases
+## CVE list
-------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------
+
-[CVE-2017-5753](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754)   | Bounds Check Bypass                                 | Spectre Variant 1
+CVE | Name | Aliases
-[CVE-2017-5715](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715)   | Branch Target Injection                             | Spectre Variant 2
+--- | ---- | -------
-[CVE-2017-5754](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754)   | Rogue Data Cache Load                               | Meltdown, Variant 3
+[CVE-2017-5753](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753) | Bounds Check Bypass | Spectre V1
-[CVE-2018-3640](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3640)   | Rogue System Register Read                          | Variant 3a
+[CVE-2017-5715](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715) | Branch Target Injection | Spectre V2
-[CVE-2018-3639](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639)   | Speculative Store Bypass                            | Variant 4
+[CVE-2017-5754](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754) | Rogue Data Cache Load | Meltdown
-[CVE-2018-3615](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3615)   | L1 Terminal Fault                                   | L1TF, Foreshadow (SGX)
+[CVE-2018-3640](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3640) | Rogue System Register Read | Variant 3a
-[CVE-2018-3620](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3620)   | L1 Terminal Fault                                   | L1TF, Foreshadow-NG (OS)
+[CVE-2018-3639](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639) | Speculative Store Bypass | Variant 4, SSB
-[CVE-2018-3646](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3646)   | L1 Terminal Fault                                   | L1TF, Foreshadow-NG (VMM)
+[CVE-2018-3615](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3615) | L1 Terminal Fault | Foreshadow (SGX)
-[CVE-2018-12126](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12126) | Microarchitectural Store Buffer Data Sampling       | MSBDS, Fallout
+[CVE-2018-3620](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3620) | L1 Terminal Fault | Foreshadow-NG (OS/SMM)
-[CVE-2018-12130](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12130) | Microarchitectural Fill Buffer Data Sampling        | MFBDS, ZombieLoad
+[CVE-2018-3646](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3646) | L1 Terminal Fault | Foreshadow-NG (VMM)
-[CVE-2018-12127](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12127) | Microarchitectural Load Port Data Sampling          | MLPDS, RIDL
+[CVE-2018-12126](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12126) | Microarchitectural Store Buffer Data Sampling | MSBDS, Fallout
+[CVE-2018-12130](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12130) | Microarchitectural Fill Buffer Data Sampling | MFBDS, ZombieLoad
+[CVE-2018-12127](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12127) | Microarchitectural Load Port Data Sampling | MLPDS, RIDL
 [CVE-2019-11091](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11091) | Microarchitectural Data Sampling Uncacheable Memory | MDSUM, RIDL
-[CVE-2019-11135](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11135) | TSX asynchronous abort                              | TAA, ZombieLoad V2
+[CVE-2019-11135](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11135) | TSX Asynchronous Abort | TAA, ZombieLoad V2
-[CVE-2018-12207](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12207) | Machine Mheck Exception on Page Size Changes        | MCEPSC, No eXcuses, iTLB Multihit
+[CVE-2018-12207](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12207) | Machine Check Exception on Page Size Changes | iTLB Multihit, No eXcuses
-[CVE-2020-0543](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543)   | Special Register Buffer Data Sampling               | SRBDS
+[CVE-2020-0543](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543) | Special Register Buffer Data Sampling | SRBDS, CROSSTalk
+[CVE-2022-29900](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29900) | Arbitrary Speculative Code Execution with Return Instructions | Retbleed (AMD)
+[CVE-2022-29901](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29901) | Arbitrary Speculative Code Execution with Return Instructions | Retbleed (Intel), RSBA
+[CVE-2022-40982](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-40982) | Gather Data Sampling | Downfall, GDS
+[CVE-2023-20569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20569) | Return Address Security | Inception, SRSO
+[CVE-2023-20593](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593) | Cross-Process Information Leak | Zenbleed
+[CVE-2023-23583](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-23583) | Redundant Prefix Issue | Reptar
+[CVE-2024-36350](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-36350) | Transient Scheduler Attack, Store Queue | TSA-SQ
+[CVE-2024-36357](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-36357) | Transient Scheduler Attack, L1 | TSA-L1
+
+## Am I at risk?
+
+Depending on your situation, the table below answers whether an attacker in a given position can extract data from a given target.
+The "Userland → Kernel" column also applies within a VM (VM userland vs. VM kernel), since the same CPU mechanisms are at play regardless of virtualization.
+
+Vulnerability | Userland → Kernel | Userland → Userland | VM → Host | VM → VM | Mitigation
+------------ | :---------------: | :-----------------: | :-------: | :-----: | ----------
+CVE-2017-5753 (Spectre V1) | 💥 | 💥 | 💥 | 💥 | Recompile everything with LFENCE
+CVE-2017-5715 (Spectre V2) | 💥 | 💥 | 💥 | 💥 | Microcode + kernel update (or retpoline)
+CVE-2017-5754 (Meltdown) | 💥 | ✅ | ✅ | ✅ | Kernel update
+CVE-2018-3640 (Variant 3a) | 💥 | ✅ | ✅ | ✅ | Microcode update
+CVE-2018-3639 (Variant 4, SSB) | ✅ | 💥 | ✅ | ✅ | Microcode + kernel update
+CVE-2018-3615 (Foreshadow, SGX) | ✅ (3) | ✅ (3) | ✅ (3) | ✅ (3) | Microcode update
+CVE-2018-3620 (Foreshadow-NG, OS/SMM) | 💥 | ✅ | ✅ | ✅ | Kernel update
+CVE-2018-3646 (Foreshadow-NG, VMM) | ✅ | ✅ | 💥 | 💥 | Kernel update (or disable EPT/SMT)
+CVE-2018-12126 (MSBDS, Fallout) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
+CVE-2018-12130 (MFBDS, ZombieLoad) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
+CVE-2018-12127 (MLPDS, RIDL) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
+CVE-2019-11091 (MDSUM, RIDL) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
+CVE-2019-11135 (TAA, ZombieLoad V2) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
+CVE-2018-12207 (iTLB Multihit, No eXcuses) | ✅ | ✅ | ☠️ | ✅ | Hypervisor update (or disable hugepages)
+CVE-2020-0543 (SRBDS, CROSSTalk) | 💥 (2) | 💥 (2) | 💥 (2) | 💥 (2) | Microcode + kernel update
+CVE-2022-29900 (Retbleed AMD) | 💥 | ✅ | 💥 | ✅ | Kernel update (+ microcode for IBPB)
+CVE-2022-29901 (Retbleed Intel, RSBA) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update (eIBRS or IBRS)
+CVE-2022-40982 (Downfall, GDS) | 💥 | 💥 | 💥 | 💥 | Microcode update (or disable AVX)
+CVE-2023-20569 (Inception, SRSO) | 💥 | ✅ | 💥 | ✅ | Microcode + kernel update
+CVE-2023-20593 (Zenbleed) | 💥 | 💥 | 💥 | 💥 | Microcode update (or kernel workaround)
+CVE-2023-23583 (Reptar) | ☠️ | ☠️ | ☠️ | ☠️ | Microcode update
+CVE-2024-36350 (TSA-SQ) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + kernel update
+CVE-2024-36357 (TSA-L1) | 💥 | 💥 (1) | 💥 | 💥 (1) | Microcode + 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 victim must share a physical core.
+
+> (2) Only leaks RDRAND/RDSEED output, not arbitrary memory; still allows recovering cryptographic material from any victim.
+
+> (3) CVE-2018-3615 (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 have OS-level access.
+
+## Detailed CVE descriptions
+
+<details>
+<summary>Unfold for more detailed CVE descriptions</summary>
+
+**CVE-2017-5753 — Bounds Check Bypass (Spectre Variant 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 equivalent 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.
+
+**CVE-2017-5715 — Branch Target Injection (Spectre Variant 2)**
+
+An attacker can poison the Branch Target Buffer (BTB) to redirect speculative execution of indirect branches in the kernel, leaking kernel memory. Two mitigation strategies exist: (1) microcode updates providing IBRS (Indirect Branch Restricted Speculation), which flushes branch predictor state on privilege 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 sensitive software.
+
+**CVE-2017-5754 — Rogue Data Cache Load (Meltdown)**
+
+On affected Intel processors, a user process can speculatively read kernel memory despite lacking permission. The CPU eventually raises a fault, but the data leaves observable 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.
+
+**CVE-2018-3640 — Rogue System Register Read (Variant 3a)**
+
+Similar to Meltdown but targeting system registers: an unprivileged process can speculatively read privileged system register values (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.
+
+**CVE-2018-3639 — Speculative Store Bypass (Variant 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. JavaScript 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 (providing the SSBD mechanism) plus a kernel update that allows affected software to opt in to the protection via prctl(). The performance impact is low to medium, depending on how frequently the mitigation is activated.
+
+**CVE-2018-3615 — 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.
+
+**CVE-2018-3620 — L1 Terminal Fault (Foreshadow-NG, OS/SMM)**
+
+A generalization of Foreshadow beyond SGX: unprivileged 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 inversion — 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 inversion is a one-time change to the page table management logic with no runtime overhead.
+
+**CVE-2018-3646 — 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 have non-present entries pointing to valid host physical addresses still resident in L1. Mitigation options include: flushing the L1 data cache on every VM entry (via a kernel update providing 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 VM entry being the most practical but still measurable on VM-heavy workloads.
+
+**CVE-2018-12126 — Microarchitectural Store Buffer Data Sampling (MSBDS, Fallout)**
+
+**CVE-2018-12130 — Microarchitectural Fill Buffer Data Sampling (MFBDS, ZombieLoad)**
+
+**CVE-2018-12127 — Microarchitectural Load Port Data Sampling (MLPDS, RIDL)**
+
+**CVE-2019-11091 — Microarchitectural Data Sampling Uncacheable Memory (MDSUM, RIDL)**
+
+These four CVEs are collectively known as "MDS" (Microarchitectural Data Sampling) vulnerabilities. They exploit different CPU internal buffers — store buffer, fill buffer, load ports, and uncacheable memory paths — that can leak recently accessed data across privilege boundaries during speculative execution. An unprivileged attacker can observe data recently processed by the kernel or other processes. Mitigation requires a microcode update (providing the MD_CLEAR mechanism) plus a kernel update that uses VERW to clear affected buffers on privilege 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.
+
+**CVE-2019-11135 — 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 vulnerabilities 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.
+
+**CVE-2018-12207 — 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 involving page size changes. This is a denial-of-service vulnerability affecting hypervisors 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-intensive workloads.
+
+**CVE-2020-0543 — 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 via speculative execution. An attacker running code on any core can observe the output of these instructions from a victim 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 speculative execution 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.
+
+**CVE-2022-29900 — 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 speculative execution and leak kernel memory, bypassing retpoline mitigations that were effective against Spectre V2. Unlike Spectre V2 which targets indirect jumps and calls, Retbleed specifically targets return instructions, which were previously considered safe. Mitigation requires a kernel update providing either the untrained return thunk (safe RET) or IBPB-on-entry mechanism, plus a microcode update providing 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.
+
+**CVE-2022-29901 — 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, via microcode update) or a kernel compiled with IBRS-on-entry support (Linux 5.19+). Call depth tracking (stuffing) is an alternative mitigation available from Linux 6.2+. Plain retpoline does NOT mitigate this vulnerability on RSBA-capable CPUs. Performance impact is medium to high.
+
+**CVE-2022-40982 — Gather Data Sampling (GDS, Downfall)**
+
+The AVX GATHER instructions can leak data from previously used vector registers across privilege boundaries through the shared gather data buffer. This affects any software using AVX2 or AVX-512 on vulnerable Intel processors. Mitigation is provided by a microcode update that clears the gather buffer, or alternatively by disabling the AVX feature entirely. Performance impact is negligible for most workloads but can be significant (up to 50%) for AVX-heavy applications such as HPC and AI inference.
+
+**CVE-2023-20569 — Return Address Security (Inception, SRSO)**
+
+On AMD Zen 1 through Zen 4 processors, an attacker can manipulate the return address predictor to redirect speculative execution on return instructions, leaking kernel memory. Mitigation requires both a kernel update (providing SRSO safe-return sequences or IBPB-on-entry) and a microcode update (providing 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.
+
+**CVE-2023-20593 — Cross-Process Information Leak (Zenbleed)**
+
+A bug in AMD Zen 2 processors causes the VZEROUPPER instruction to incorrectly zero register files during speculative execution, leaving stale data from other processes observable in vector registers. This can leak data across any privilege boundary, including from the kernel and other processes, at rates up to 30 KB/s per core. Mitigation is available 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.
+
+**CVE-2023-23583 — 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 privilege escalation. Any software running on an affected CPU can trigger the bug. Mitigation requires a microcode update. Performance impact is low.
+
+**CVE-2024-36350 — Transient Scheduler Attack, Store Queue (TSA-SQ)**
+
+On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculatively retrieve stale data from the store queue during certain timing windows, allowing an attacker to infer data from previous store operations across privilege boundaries. The attack can also leak data between SMT sibling threads. Mitigation requires both a microcode update (exposing the VERW_CLEAR 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 active. Performance impact is low to medium.
+
+**CVE-2024-36357 — Transient Scheduler Attack, L1 (TSA-L1)**
+
+On AMD Zen 3 and Zen 4 processors, the CPU's transient scheduler may speculatively retrieve stale data from the L1 data cache during certain timing windows, allowing an attacker to infer data in the L1D cache across privilege boundaries. Mitigation requires the same microcode and kernel updates as TSA-SQ: a microcode update exposing VERW_CLEAR and a kernel update (CONFIG_MITIGATION_TSA, Linux 6.16+) that clears CPU buffers via VERW on privilege transitions. Performance impact is low to medium.
+
+</details>
+
+## Unsupported CVEs
+
+Several transient execution CVEs are not covered by this tool, for various 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 available in the
+[UNSUPPORTED_CVE_LIST.md](https://github.com/speed47/spectre-meltdown-checker/blob/source/UNSUPPORTED_CVE_LIST.md) file.
+
+## Scope
 
 Supported operating systems:
 - Linux (all versions, flavors and distros)
@@ -27,7 +182,7 @@ Supported operating systems:
 
 For Linux systems, the tool will detect mitigations, including backported non-vanilla patches, regardless of the advertised kernel version number and the distribution (such as Debian, Ubuntu, CentOS, RHEL, Fedora, openSUSE, Arch, ...), it also works if you've compiled your own kernel. More information [here](FAQ.md#how-does-this-script-work).
 
-Other operating systems such as MacOS, Windows, ESXi, etc. [will most likely never be supported](FAQ.md#why-is-my-os-not-supported).
+Other operating systems such as MacOS, Windows, ESXi, etc. [will never be supported](FAQ.md#why-is-my-os-not-supported).
 
 Supported architectures:
 - `x86` (32 bits)
@@ -37,15 +192,13 @@ Supported architectures:
 
 ## Frequently Asked Questions (FAQ)
 
-- What is the purpose of this tool?
+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?
-- 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) have detailed answers in the [FAQ](FAQ.md), please have a look!
 
-## Easy way to run the script
+## Running the script
+
+### Direct way (recommended)
 
 - Get the latest version of the script using `curl` *or* `wget`
 
@@ -67,22 +220,30 @@ chmod +x spectre-meltdown-checker.sh
 sudo ./spectre-meltdown-checker.sh
 ```
 
-### Run the script in a docker container
+### Using a docker container
 
-#### With docker-compose
+<details>
+<summary>Unfold for instructions</summary>
+
+Using `docker compose`:
 
 ```shell
-docker-compose build
+docker compose build
-docker-compose run --rm spectre-meltdown-checker
+docker compose run --rm spectre-meltdown-checker
 ```
 
-#### Without docker-compose
+Note that on older versions 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:
 
 ```shell
 docker build -t spectre-meltdown-checker .
 docker run --rm --privileged -v /boot:/boot:ro -v /dev/cpu:/dev/cpu:ro -v /lib/modules:/lib/modules:ro spectre-meltdown-checker
 ```
 
+</details>
+
 ## Example of script output
 
 - Intel Haswell CPU running under Ubuntu 16.04 LTS
@@ -97,84 +258,3 @@ docker run --rm --privileged -v /boot:/boot:ro -v /dev/cpu:/dev/cpu:ro -v /lib/m
 
 ![batch](https://user-images.githubusercontent.com/218502/108764902-71634a80-7553-11eb-9678-fd304995fa64.png)
 
-## Quick summary of the CVEs
-
-**CVE-2017-5753** bounds check bypass (Spectre Variant 1)
-
-   - Impact: Kernel & all software
-   - Mitigation: recompile software *and* kernel with a modified compiler that introduces the LFENCE opcode at the proper positions in the resulting code
-   - Performance impact of the mitigation: negligible
-
-**CVE-2017-5715** branch target injection (Spectre Variant 2)
-
-   - Impact: Kernel
-   - Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors)
-   - Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it
-   - Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
-
-**CVE-2017-5754** rogue data cache load (Meltdown)
-
-   - Impact: Kernel
-   - Mitigation: updated kernel (with PTI/KPTI patches), updating the kernel is enough
-   - Performance impact of the mitigation: low to medium
-
-**CVE-2018-3640** rogue system register read (Variant 3a)
-
-   - Impact: TBC
-   - Mitigation: microcode update only
-   - Performance impact of the mitigation: negligible
-
-**CVE-2018-3639** speculative store bypass (Variant 4)
-
-   - Impact: software using JIT (no known exploitation against kernel)
-   - Mitigation: microcode update + kernel update making possible for affected software to protect itself
-   - Performance impact of the mitigation: low to medium
-
-**CVE-2018-3615** l1 terminal fault (Foreshadow-NG SGX)
-
-   - Impact: Kernel & all software (any physical memory address in the system)
-   - Mitigation: microcode update
-   - Performance impact of the mitigation: negligible
-
-**CVE-2018-3620** l1 terminal fault (Foreshadow-NG SMM)
-
-   - Impact: Kernel & System management mode
-   - Mitigation: updated kernel (with PTE inversion)
-   - Performance impact of the mitigation: negligible
-
-**CVE-2018-3646** l1 terminal fault (Foreshadow-NG VMM)
-
-   - Impact: Virtualization software and Virtual Machine Monitors
-   - Mitigation: disable ept (extended page tables), disable hyper-threading (SMT), or updated kernel (with L1d flush)
-   - Performance impact of the mitigation: low to significant
-
-**CVE-2018-12126** [MSBDS] Microarchitectural Store Buffer Data Sampling (Fallout)
-
-**CVE-2018-12130** [MFBDS] Microarchitectural Fill Buffer Data Sampling (ZombieLoad)
-
-**CVE-2018-12127** [MLPDS] Microarchitectural Load Port Data Sampling (RIDL)
-
-**CVE-2019-11091** [MDSUM] Microarchitectural Data Sampling Uncacheable Memory (RIDL)
-
-   - Note: These 4 CVEs are similar and collectively named "MDS" vulnerabilities, the mitigation is identical for all
-   - Impact: Kernel
-   - Mitigation: microcode update + kernel update making possible to protect various CPU internal buffers from unprivileged speculative access to data
-   - Performance impact of the mitigation: low to significant
-
-**CVE-2019-11135** TSX Asynchronous Abort (TAA, ZombieLoad V2)
-
-   - Impact: Kernel
-   - Mitigation: microcode update + kernel update making possible to protect various CPU internal buffers from unprivileged speculative access to data
-   - Performance impact of the mitigation: low to significant
-
-**CVE-2018-12207** machine check exception on page size changes (No eXcuses, iTLB Multihit)
-
-   - Impact: Virtualization software and Virtual Machine Monitors
-   - Mitigation: disable hugepages use in hypervisor, or update hypervisor to benefit from mitigation
-   - Performance impact of the mitigation: low to significant
-
-**CVE-2020-0543** Special Register Buffer Data Sampling (SRBDS)
-
-   - Impact: Kernel
-   - Mitigation: microcode update + kernel update helping to protect various CPU internal buffers from unprivileged speculative access to data
-   - Performance impact of the mitigation: low

docker-compose.yml

@@ -1,5 +1,3 @@
-version: '2'
-
 services:
   spectre-meltdown-checker:
     build: