The key idea of this attack is to use some kind of non-privileged system event that happens on occasion in normal software, but is never extremely frequent. This event is used to charge a small capacitor inside the trigger. When the capacitor fills to a high enough level, it will read as a logical 1 (or 0, or whatever... it will toggle.)
This image shows the triggering event on top and the capacitor charge in the middle. Once the capacitor charge exceeds the threshold (red line), the hardware exploit is triggered and the malicious software can now take over the system:
During ordinary operation, the triggering event is too rare to ever cause the capacitor to completely fill (the capacitor will naturally lose charge over time due to leakage). But if the attacker can run non-privileged software on the CPU, he can trigger the attack by performing this rare event in a massive burst. The example used in the paper is the divide-by-zero flag but any suitable signal in the CPU could be used instead. The key is that no normal workload would ever saturate the divide-by-zero flag in the way that the malicious user code does. And since it is not privileged code, it is able to run normally, as for example through JavaScript running in a browser tab. Once the capacitor is fully charged, the CPU's privilege logic will be temporarily corrupted (until the capacitor discharges through leakage) and the malicious software is now free to execute instruction bytes that contain kernel-privilege code that would ordinarily cause the software to generate a fault and be terminated. And once the attacker has his toe in the door, he can just perform a full transition to escalated privilege-level and run whatever code he wants from there on out.
The trigger is remarkable because it simultaneously achieves two goals that seem mutually exclusive at first glance: it is both stealthy (hard to detect through testing) and small. And it works.
Lots of lessons in this paper...
