Dynamic mitigations
summary
Cloud VMs can change CPU mitigation policy at runtime via a writable sysfs reconfiguration interface that accepts bug-style kernel options and causes the kernel to re-evaluate and repatch alternatives, retpolines and feature bits. Repatching uses a freezer and a new stop_machine NMI path, takes about 50 ms, and caught several upstream bugs during testing. Measured impact: cumulative mitigations cost ~20% on average and >50% on some workloads; current set includes about 16 mitigation switches and BPF jits may need reload after changes.
AI-written summary · about
chapters (18)
- 0:00Introduction to mitigations
- 1:24Performance impact of mitigations
- 2:27Why dynamic mitigations
- 3:10Cloud deployment use case
- 4:35Mitigation changes and testing
- 6:23Implementation and RFC concerns
- 7:24Community feedback and concerns
- 11:37Simpler mitigations for users
- 15:14DebugFS and production risks
- 18:41DebugFS as an ABI problem
- 21:12Server space focus
- 23:03Out-of-tree adoption and urgency
- 24:06Alternative API locations
- 26:15Fine-grained mitigation control
- 26:59BPF limitations
- 28:22Repatching flow and big hammers
- 31:56Stop machine NMI details
- 33:02Emergency use case justification
related talks
42mSpectre and Meltdown vs. Real-Time: How Much do Mitigations Cost?
45mInside Google's Discovery and Remediation of a Critical CPU Vulnerability
30mSpectre, Meltdown, & Linux
19mKeynote: MDS, Fallout, Zombieland & Linux
34mGetting on the Same (Virtual Memory) Page: A Roundtable on Data-only Attack Mitigations
44mInside Google's Discovery and Remediation of a Critical CPU Vulnerability
43m“Closing Panel: Spectre”
18mKernel Live Patching: Mitigating CVEs With Zero Downtime