4 ms·

I don't blame the researchers, this is specifically against the nonsense discussions that plague this thread and others like it talking about the performance im

I don't blame the researchers, this is specifically against the nonsense discussions that plague this thread and others like it talking about the performance impact on personal computers. These side-channel bugs are minor annoyances, and mostly a problem for cloud providers. I wouldn't want Intel or AMD or anyone else to abandon speculative execution, clock boosting, or any other of the "vulnerable" technologies just because their unsafe in specific application spaces, which seems to be what half of HN starts advocating for whenever this stuff comes up. An application bug like OpenSSH is a completely separate spiritually from the hardware bugs that inspire these mitigation discussions.

ziddoap 4y ago
I agree on almost all fronts. The person I replied to asserted that all timing attacks are theatre, which I disagree with (and, evidently, poorly communicated my stance). Perhaps they did not mean the entire class of vulnerabilities which rely on some sort of exploitable timing difference, but only those that require privileged (or physical) access. In that case, I still believe it is foolish to completely dismiss them simply for being a 'timing attack' (and therefor theatre), but I also believe it is foolish to blindly follow mitigation recommendations without analysis.
noobermin 4y ago
Another example, I work in scientific high performance computing. The worst that can happen with my work (although people in more defense oriented research might care) is someone might see my data before I publish it...woopy doo, and I guess if they do, they'll have to spend the few hours needed to process TBs of data I make so they can what, scoop me? Oh and they have to access to the same supercomputer too... the risk I face of anything bad happening to me is minuscule. On the other hand, removing modern processor features like speculative execution and frequency scaling would mean my increase in execution time would mean going from 3 weeks or so to 4 weeks or more per simulation? No, I am NOT okay with that at fucking all, it's hard enough dealing with the multiweek delay I have before I can iterate, making that even longer for very little risk is not worth it.

ziddoap 4y ago

I agree on almost all fronts. The person I replied to asserted that all timing attacks are theatre, which I disagree with (and, evidently, poorly communicated my stance). Perhaps they did not mean the entire class of vulnerabilities which rely on some sort of exploitable timing difference, but only those that require privileged (or physical) access. In that case, I still believe it is foolish to completely dismiss them simply for being a 'timing attack' (and therefor theatre), but I also believe it is foolish to blindly follow mitigation recommendations without analysis.

noobermin 4y ago

Another example, I work in scientific high performance computing. The worst that can happen with my work (although people in more defense oriented research might care) is someone might see my data before I publish it...woopy doo, and I guess if they do, they'll have to spend the few hours needed to process TBs of data I make so they can what, scoop me? Oh and they have to access to the same supercomputer too... the risk I face of anything bad happening to me is minuscule. On the other hand, removing modern processor features like speculative execution and frequency scaling would mean my increase in execution time would mean going from 3 weeks or so to 4 weeks or more per simulation? No, I am NOT okay with that at fucking all, it's hard enough dealing with the multiweek delay I have before I can iterate, making that even longer for very little risk is not worth it.