Sorry for my skepticism, but even in old systems, wouldn't such a time would be too small to measure even by a program on the same computer? and I imagine that having a preemptive scheduler makes things even more complicated.

It's hard to imagine the attack you describe being viable.

You'll be surprised, but yes - it can be measured. Not even on same computer, but across different computers on Internet, even with all the random latency in the middle.

The idea is that you don't measure only once. You measure thousands, tens of thousands of times and more. Then any difference however small it will be also multiplied thousand times and it will be possible to measure it. Even if you will have other random processes such as OS scheduler, network latency, etc - it will be pretty obvious after thousands of measurements which ones to ignore. For example, check the histogram graphs in this paper: https://mlq.me/download/netspectre.pdf

My understanding of timing attacks is that they can be used when you can trigger the code path thousands of times quickly. This gives you execution time averages and distributions. Also, they're typically used against cryptographic hash functions which are more expensive than just a string compare.

https://en.wikipedia.org/wiki/Timing_attack

But if you use cryptographic hash functions, then you can't do the timing attack described because any one character change changes the whole hash.

Not for cracking a password perhaps, but imagine you have a system that looks at a MAC'd ciphertext. You want the system to attempt to decrypt a malicious ciphertext you've generated, but it won't until you have passed its MAC check.

With a timing attack, you can iterate the bytes of the MAC, itself probably based on a cryptographic hash like HMAC(sha256), until you get something that gets to the second stage.

You reduce MAC-forging complexity from 2 to the power of the number of MAC bits, to 256 times the number of bytes in the MAC.

Yup, that's why this attack doesn't really work on hash functions.

> It's hard to imagine the attack you describe being viable.

This has been the conventional thinking of software engineers for the past few decades. It turns out to be completely wrong.

I mean who would have thought measuring memory access latency could turn speculation into an arbitrary kernel read gadget yet here we are.