News for hackers. Stuff that matters.
Re:Hertzbleed Attack by jabart on Tuesday June 14, 2022 @06:56PM (#31747028)
My understanding was that the timer precision was limited and that was never re-enabled.

From MDN.

"It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the returned time to 1 millisecond increments."

Re:Hertzbleed Attack by josefx on Wednesday June 15, 2022 @06:42AM (#31751172)
If I remember correctly they also had to disable shared array buffers because a thread just incrementing a shared value can be used as timer.
Re:Hertzbleed Attack by contravariant on Tuesday June 14, 2022 @07:34PM (#31747349)
Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?
Re:Hertzbleed Attack by thristian on Tuesday June 14, 2022 @10:56PM (#31748628)
Same as any security: making an attack more expensive to mount means people are less likely to try it. If high-resolution timers allow you to mount an attack in the three minutes the target takes to read a listicle page, then rounded timers require the target to keep the page open in the foreground for 3000 minutes, or 50 hours. That's much more difficult to do.
Re:Hertzbleed Attack by vajrabum on Tuesday June 14, 2022 @10:05PM (#31748324)
Isn't rounding pretty much the same thing as throwing away some precision in this case? So if I drop some (enough) bits and add .5 then no amount of averaging is going to recover the lost precision. Or maybe I misunderstand?
Re:Hertzbleed Attack by danielheath on Tuesday June 14, 2022 @11:22PM (#31748774)
Example: You need to know how whether an operation takes 30 or 31 milliseconds, but your timer is rounded to the nearest 100ms, so you just get 0 or 100.

If you repeat the operation 100 times and time how long that takes, you should either get 3000 or 3100 milliseconds.

Re:Hertzbleed Attack by usrusr on Wednesday June 15, 2022 @03:26AM (#31750076)
..and a dramatically increased likelihood of something unrelated going on in the system ruining your results. It's easy to dismiss mitigations like this as "not a solution", but at least those that add uncertainty to sidechannel attacks seem to complement each other quite nicely. Uncertainties don't add, they multiply.
Re:Hertzbleed Attack by SOLAR_FIELDS on Tuesday June 14, 2022 @09:51PM (#31748243)
I know next to nothing about the internals of how the rounding code works, but couldn't randomly choosing to round up or down mitigate this somewhat?
Re:Hertzbleed Attack by arpafaucon on Wednesday June 15, 2022 @02:09AM (#31749660)
If you round up and down with the same probability, it will get canceled on the long run.

I suppose this does mitigate the risk a little, but risks breaking other things. For example, you don't have the simple logic sequence: a < b => round(a) < round(b)

So I'd say "not worth it"

Re:Hertzbleed Attack by rswail on Wednesday June 15, 2022 @04:31AM (#31750474)
Minor correction:

iff |a| < |b| then round(|a|) < = round(|b|)