The person this lands on is whoever owns kernel patch policy: an operating-system update turns up carrying a microarchitectural mitigation, there is no symptom anyone can point at, and a reboot window has to be negotiated with people who do not want one. On AMD hardware, that negotiation is most of the work, because AMD has already released a mitigation delivered through OS updates [13].
The mechanism is worth reading closely, and it comes down to ordering. Existing defenses do two things to the processor's prediction machinery: wipe it, and isolate it before predictions get used. Trujillo and Yan found those two actions cannot happen at the same moment, which leaves a short window where the machinery can be dirtied again [4]. Interrupt injection walks in through that window: a program tunes a timer precisely enough that the interrupt handler runs inside the gap and alters the predictor before the processor relies on it [5]. The timers involved are ones ordinary programs can configure [6].
AMD's saferet narrows that gap to two instructions, tens of nanoseconds in practice [9]. The team hit it anyway by slowing the processor at the targeted point [10]. On Intel, the newer hardware defense held on one generation and failed on another [8], which pushes the unit of fleet inventory down from vendor to chip generation.
Now the arithmetic the write-up actually documents. On an AMD box running a current Linux kernel, the researchers first beat the measure that randomizes where the operating system sits in memory, succeeding in all 10 attempts at roughly nine minutes each [11]. That is about 90 minutes of machine time before any protected memory gets read [16]. The headline on the report says five attempts [17]. What the body supports is a 100 percent hit rate on the location step and a demonstrated read of the root password file [3].
The awkward part for maintainers is the proposed repair. Cleaning the prediction machinery again after an interrupt finishes looks viable on AMD, and could make attacks more reliable on some Intel systems [14]. One kernel change fixes the problem in one column and opens a regression in the other.
The sorting question turns on two axes: whether code you did not write runs on your cores, and whether you know your machines by chip generation rather than by vendor logo. If both are true, you can act on the Intel generation split today. If you run unknown code but have not sorted your fleet by generation, the inventory is the task ahead of you, not the patch. If you track generations but are not exposed to unknown code, the AMD update can wait for the next scheduled maintenance window. If neither applies, you are relying on nobody getting local execution, which is a position, just not a mitigation. This class of bug has been in the open since Spectre in 2018 [15], so the inventory is the part that keeps paying.
