[anyfoo]

I'm not an expert, but I think you can only make this harder by intentionally making timers less precise (even adding some random fuzz). Someone may correct me if I'm wrong, but I think statistically, a less precise timer means you will just need a longer runtime.

Suppose you want to measure the distribution of the delay between recurring events (which is basically what's at the heart of those vulnerabilities). Suppose the delays are all sub-milliseconds, and that your timer, to pick something ridiculous, only has a 2 second granularity.

You may at first think that you cannot measure the sub-millisecond distribution with such a corse timer. But consider that event and timers are not synchronized to each other, so with enough patience, you will still catch some events barely on the left or on the right side of your 2 second timer tick. Do this over a long enough time, and you can reconstruct the original distribution. Even adding some randomness to the timer tick just means you need more samples to suss the statistic out.

Again, I am not an expert, and I don't know if this actually works, but that's what I came up with intuitively, and it matches with what I heard from some trustworthy people on the subject, namely that non-precision timers are not a panacea.

[teruakohatu]

> Even adding some randomness to the timer tick just means you need more samples to suss the statistic out.

If each timer draws from the same random distribution then sure, you could work out the real tick with greater accuracy, but I don’t know if that is practical.

If the timers draw from different distributions then it is going to be much harder.

I imagine there is an upper limit of how much processing can be done per tick to before any attack becomes implausible.

[anyfoo]

> If the timers draw from different distributions then it is going to be much harder.

Again, I'm an amateur, but I think you just need to know that distribution, which I guess you usually do (open source vs. closed source barely matters there), law of large numbers and all.

Anyway, looking through literature, this article presents some actual ways to circumvent timers being made corse-grained: https://attacking.systems/web/files/timers.pdf

In that article, the "Clock interpolation" sounds vaguely related to what I was describing on a quick read, or maybe it's something else entirely... Later, the article mentions alternative timing sources altogether.

Either way, the conclusion of the article is that the mitigation approach as a whole is indeed ineffective: "[...] browser vendors decided to reduce the timer resolution. In this article, we showed that this attempt to close these vulnerabilities was merely a quick-fix and did not address the underlying issue. [...]"

[vlovich123]

I believe your understanding of the literature is correct (I too am an amateur when it comes to side channel attacks). My memory is vague here but I believe that while it still lets you exploit side channels, it still requires extra time to do so which lowers the throughput you get out of the gadget.

[vlovich123]

They are not a panacea (in some cases - the way Cloudflare Workers does them it does more effectively limit attacks vs how browsers have to work) but slowing down an attack is valuable because it can make the attack infeasible because your ability to retrieve anything damaging is bounded by how long you visit that website.

[anyfoo]

Fair. Better than nothing.