Hacker News Reader

Comment by Osiris | Hacker News Reader

With all the news about these attacks lately, this is one of the best posts I've seen in explaining to less knowledgable people how exactly speculation causes a problem.

One question I still have that gets glossed over is how timing of instructions is captured.

View on HN

in order to exploit it from a script running in a web-browser: there's a high-resolution timer in javascript. This one is limited to 5 to 20 us resolution to prevent such attacks.

Recently a shared-memory extension has been proposed. one javascript thread just increments a counter in the shared memory, functioning as a clock for the other thread.

In both cases, (Spectre) attacks can be prevented by browser updates, so any performance impact is not system wide.

This is different from Meltdown, which (only?) affects intel. That one requires kernel changes which cause system-wide performance degradation.

> This one is limited to 5 to 20 us resolution to prevent such attacks.

* make such attacks more difficult.

Impossible. This attack relies on detecting the timing between a cache hit and miss. If your clock resolution is larger than a cache miss then you can't differentiate the two events and so no information is leaked.

Not quite. An instruction that takes 1us is much less likely to start and end in a different 20us clock cycle than a 10us instruction. Simple repeated sampling combined with statistics still yields a timing attack. It'll be slower and less deterministic, but it's still a problem.

You can wait for a random period on the scale of the clock then measure and take statistics on the results. It will slow down the attack but not stop it.

Right, but all this does is close off one possible avenue for a clever attacker to cobble together an HRT. Given the sheer number of JS APIs that have been thrown into browsers, I think it's pretty naive to imagine that we've closed off the only possible avenue to jury-rig a sufficiently precise measure of time.

The GPS signal in below thermal noise at ambient temperature [1]. Using your logic you would say that then it would be impossible to extract. However, with clever math you can extract a signal which is below the noise floor.

Particle physicists are experts at this, extracting tiny signals from huge piles of noisy data.

[1] https://sdrgps.blogspot.co.uk/2016/02/find-signal-in-noise.h...

I've been pondering how to identify the cached line without a timer. It seems like a classical race condition if multiple reads can be issued at once, eg by ILP. Another thread could easily figure out which load completes first.

> 5 to 20 μs resolution

Updated for those of μs confμsed by this μngainly grammar

One way would be to use the rdtsc instruction, which reports how many cycles have been executed since the processor was reset.

Which is precisely why Firefox is releasing an update that tweaks high resolution timing. I guess tweaks probably means breaks for some uses cases but that’s likely unavoidable and worth it.

I defintiely agree

Using rdtscp is better in this case than rdtsc, because it's a serializing instruction. So speculation (instruction reordering) itself doesn't affect the results.

Reply on news.ycombinator.com