Indeed. One fun example is LHC[1], where the probability of a proton in a single bunch hitting a proton in the bunch going the opposite direction is on the order of 10^-21, yet due to huge number of protons per bunch and large number of bunches per second, it still results in ~10^9 collisions per second.
[1]: https://www.lhc-closer.es/taking_a_closer_look_at_lhc/0.lhc_...
I could not find any info about that bug, anyone got a link or a source?
Read i into register.
Add one to that register.
Write i back to the memory location.
And there's a window during that "add one to the register" where you can obviously have something jump in and write something else to that memory location.What happens on your real processor is more complicated since this is going to relate to cache coherency between the processors, not directly writing RAM at that point, and that's a deep rabbit hole. I couldn't describe it all in detail anyhow. But I can observe it doesn't take much at all to turn that one cycle vulnerability into something with a larger target.
https://www.ted.com/talks/del_harvey_protecting_twitter_user...
Any time your service has a high TPS, your API gets a lot of calls, a button in your app gets pressed a lot, ... this applies.
Critically, "a lot" is defined relative to your failure tolerance. It may actually be very fast or a lot, or not particularly fast but it really really needs to work.
It highlights the fallacy of equating "low probability" and "won't happen".
[1] https://docs.microsoft.com/en-us/archive/blogs/larryosterman...