Thanks for reading! The two stories are of course deeply intertwined: we wouldn’t have found the new side channel without the cautionary tale about machine learning.

But the finding about ML misinterpretation is particularly notable because it calls a lot of existing computer architecture research into question. In the past, attacks like this were very difficult to pull off without an in-depth understanding of the side channel being exploited. But ML models (in this case, an LSTM) generally go a bit beyond “statistics” because they unlock much greater accuracy, making it much easier to develop powerful attacks that exploit side channels that aren’t really understood. And there are a lot of ML-assisted attacks created in this fashion today: the Shusterman et al. paper alone has almost 200 citations, a huge amount for a computer architecture paper.

The point of publishing this kind of research is to better understand our systems so we can build stronger defenses — the cost of getting this wrong and misleading the community is pretty high. And this would technically still be true even if we ultimately found that the cache was responsible for the prior attack. But of course, it helps that we discovered a new side channel along the way — this really drove our point home. I probably could have emphasized this more in my blogpost.

yes - I also feel this does not have strong new findings about ML except some common sense that all ML practitioners should have: that is, do not interpret ML results as cause-and-effect explanations when the data you have captured and modelled does not warrant it.

Maybe in the real world, this common sense gets lost in the deluge of correlations when people are immersed in a sea of data -- but good experiment design and peer review should ideally sift out any unsound conclusions and interpretations -- which, to be fair, this replication study does an excellent job of!

Well done, and good luck to the OP!

Almost didn't read it because of the length and how it starts. Generally I just want the meat, not the backstory. But your comment convinced me to read it, and it is indeed great!

Being at the good place with the good people is indeed a very important factor for succeeding or not. In my first PhD experience in Japan my professor and the others just kept criticizing whatever I proposed for 3 years without giving me actionable ideas. The prof in the lab next door loved my research, sadly I found him too late to switch lab. Now I'm at a place with half of the people in the country that can understand fully another project of mine and give a shit (that's a grand number of 2 people), and my project already benefited from some of their data. Plus the director likes me too and includes my in the lab activity even if I'm not officially affiliated to the lab. Now, that's the environment I can succeed in. My take way is finding the right environment and people may be difficult, but it's crucial other even very good work is done for nothing.

Thank you! Really appreciate it

Websites doing this would have to be careful about it: they might become the only website triggering a lot of interrupts randomly, which then makes them easy to identify.

Our countermeasure which triggers interrupts randomly is implemented as a browser extension, the source code for which is available here: https://github.com/jackcook/bigger-fish

I'm not sure I would recommend it for daily use though, I think our tests showed it slowed page load times down by about 10%.

I'm on safari/macOS, and many of the counting related demonstrations did not vary as much as claimed -- some did, with significant computer use, but I'd bet some mitigations have been implemented already in Safari.

Nevertheless, EXTREMELY cool paper.

As far as browsers are concerned the actual solution is banning Javascript from regular Web. JS is basically remote code execution (even more so since JIT became the norm); it is a terrible idea that will continue to create all sorts of problems.

My suspicion is that io_uring itself mitigates syscall overhead but doesn't do anything to change interrupts.

You could probably do things at the OS level to change interrupt behavior in a way that would mitigate this attack significantly, I'll need to read the paper to see if they discuss this.