Egy rövid karesgéléssel még nem sikerült belefutnom example kódba. A Meltdown ill Spectre publikációkban említik, mint felmerült és elvetett védekezési lehetőséget.
Itt találtam egy hoszasabb magyarázatot (ez elsőre valami podcast leiratának tünik):
https://www.grc.com/sn/sn-600.txt
Browsers years ago in response to those attacks which we covered on the podcast, they decided, okay, we're not going to give JavaScript super granular timing information. The browsers, both Firefox and Chrome, reduced the resolution of the API, which captures the current instant in time from infinity. It used to be the resolution of the clock. So it was nanoseconds. They reduced it to five microseconds. So they deliberately removed resolution so that JavaScript could not determine as accurately as it originally could what time it was. So once again, not to be daunted, our clever engineers said, okay, fine. We don't have accurate timing. But is the five microseconds itself accurate?
And it turns out that Chrome and Firefox differ a little bit. Chrome is a little trickier. They fudge the actual timing event. It still has five microseconds' resolution. But they delay it a couple different amounts in order to, like, further obscure the actual moment of that five microseconds event. Firefox didn't do that. So, for example, in Firefox the way you solve this problem is you query the API until the timer ticks. So that gives you tick alignment. Then you perform the operation that you want to time, in this case a read or a write of a certain location because you're wanting to probe the cache. And as soon as you get control back from that operation, you start doing something, you start counting how many times you can go in a loop until the next timer tick.
And so what happens is essentially the five microsecond resolution puts fenceposts. And you align yourself with one fencepost at five microseconds, do something, and the moment you get back, you spin until the next fencepost, until the next value, the next five microsecond tick occurs.
[...]
There's another approach using WebWorkers, which essentially extends the JavaScript API to a multithreaded environment, where you're able to say, you go off and do this. Oh, and you also - the workers, in order to coordinate, they have a region of shared memory, memory that they can both see.
So the WebWorker, you give it the task of simply spinning up a counter in the shared memory as fast as it can. Now you have your own timer, which you're able to use, which is, again, much higher resolution than the deliberately blunted resolution of the JavaScript timer in order to determine how long something took to occur.
Amint látható többféle megoldás is van, a webworker nem is feltétlen kell. Ha az órának csak felbontását csökkentik le (mondjuk lemaszkolják az alsó biteket), attól még az értékének ugrásszerű lépései pontos frekvenciával történnek, ezt pedig lehet esemény-illesztésre használni egy szálon belül is. A Chrome-ban ezért még szándékosan jitterelik is órát. Viszont a webworker-es megoldásnak tudomásom szerint ezidáig nincs hatékony ellenszere.
---
Régóta vágyok én, az androidok mezonkincsére már!