4 ms·

Sandy Bridge was hit harder than newer generations by those mitigations. It was a factor in my decision to retire my i5-2500k 5 years ago.

• pantalaimon 3y ago
  On a personal machine, it's perfectly reasonable to set mitigations=off - the only place where I run untrusted code is the browser, and browsers had mitigations very early on.
  • sweetjuly 3y ago
    Browser mitigations are about protecting other parts of the browser from JS. Attacks against the kernel are intentionally left out of scope of these mitigations on the assumption that kernel mitigations will handle both JS->kernel as well as any other user process->kernel.
    • pantalaimon 3y ago
      Those cache attacks rely on accurate timing because the method of data exfiltration is faster access to array members that were cached in a speculative access. By fudging the time (JS doesn't need ns or even µs accuracy) those issues are pretty much solved.
      • sweetjuly 3y ago
        That's not true...at all. There are amplification techniques which work in JS and wasm that amplify a cache eviction into an over 1s delta [1]. Trying to restrict timing as a mitigation has been known to be ineffective since 2019, a bunch of people at Google who worked on the mitigation in Chromium wrote a paper [2] saying as much. Site isolation is the chosen mitigation because it actually works. [1] https://www.youtube.com/watch?v=Hx6IVymJ8ZM https://www.youtube.com/watch?v=Hx6IVymJ8ZM [2] https://arxiv.org/pdf/1902.05178.pdf https://arxiv.org/pdf/1902.05178.pdf