OSDev.org

Sik wrote:OK the more stuff gets disclosed the more things seem to change so huuuuh screw it. How do Meltdown and Spectre actually work?

// flush caches
if index1 < array1.length {
  value1 = array1[index1] // index1 is bogus, pointing to kernel address
  index2 = (value1 & 1) * 0x100 + 0x200 // index2 := 0x100 or 0x300
  if index2 < array2.length {
    value2 = array2[index2]  // legal access
  }
}

mov rax, [kernel_address] // trigger exception, which can be handled gracefully and return rax = 0
and rax, 1
mov rbx, [user_address + rax* 0x100]

Korona wrote:Note that, contrary what ~ believes, neither Spectre nor Meltdown depend on sensitive data being in the cache. The attacks only use the cache to measure timings, they do not access, read, or extract the contents of the cache. In particular, the attacks only access cached auxiliary buffers (containing random data) and not the cache lines that contain real data.

• Trick the CPU into reading the byte you want to snoop into the cache
• Mask (AND) the value with the bit you want to get
• Use said bit as part of an offset for an address
• Try to read from the address that would be used if the bit was 1

Sik wrote:We need better sandboxing and not just for scripts. Take a media player: why should the codec have direct access to the file it's taking, rather than just being given a stream? Or why should the GUI have direct access to that when it just needs to send commands and query the current state? Etc.

Korona wrote:The are Spectre proof-of-concepts that read your Chrome passwords from JavaScript (even though Chrome already randomizes its timing functions). Spectre is definitely useful.

Korona wrote:Actually, browsers already isolate some components into own processes (e.g. Flash and other plugins). However, JavaScript needs to be able to access the DOM, so it cannot be separated from the rendering.

Korona wrote:Meltdown can be fixed in hardware by only speculating executing code from the same privilege level. Spectre is harder to fix as it does not violate hardware privilege levels and only attacks software isolation.

Sik wrote:Yeah (or just marking the relevant cache row as invalid, don't even bother flushing it), though that may be harder to implement than it sounds since a mispeculated access may share a row with an access that was intended (which wouldn't be the case in Spectre, but more likely to be the case with normal code, and as such needs to be handled). May be doable though, albeit only in new CPUs of course.

It does leave us wondering if there are other cache-induced potential exploits though. In fact, mispeculation causing data loading into cache already has another side effect, which is to needlessly hamper performance of the program (as it's inevitably evicting other cached data), but getting rid of speculation will harm the performance of CPUs overall. Of course this would be much less dangerous than exposing data it shouldn't =P