5 ms·

Okay, one thing I don't get: Fundamentally, the Meltdown problem comes from a process getting to inspect the wreckage after the the CPU tried to clean up access

• jchw 9y ago
  Because other than the flaw that leaks information, speculative execution of instructions that never retire leave absolutely no trace at all. There's nothing to detect.
  • willtim 9y ago
    Not true. It turns out that Speculative evaluation has side-effects, it changes the contents of the cache. This is the big issue. The contents of the cache are then detectable with timing attacks (the Spectre variants, but perhaps more will be discovered). Meltdown combines this flaw with Intel's own "surprising design" of speculative evaluation, which omits security checks and pulls kernel memory into the cache.
    • jchw 9y ago
      Yes that's what I was saying: >other than the flaw that leaks information, But that flaw is pretty hard or impossible to detect.
• conradev 9y ago
  Speculative execution executes code that might not actually run. The following example could access protected memory even if `has_privileges` is false (i.e. the processor predicts it might be true): if (has_privileges) { // Access protected memory } else { // Do something else }
• apendleton 9y ago
  My understanding: Because it may not be known whether or not the read will have ended up being prohibited at the time it's speculatively executed. Think of a simple for loop over the contents of an array: usually at the end of each loop iteration you jump back to the beginning of the loop, until the last time you don't, when i > array.length or whatever. The branch predictor will likely predict that the last time you'll jump back again (you always have before, and it doesn't know the actual value of array.length yet since that takes hundreds of cycles to come back from memory) and try to speculatively execute the contents of the loop body on what turns out to be out-of-bounds data. That's not typically malicious; it's at the end of pretty much every iteration over an array ever. So then, if we can reliably get our loop to operate on a bit of data that might turn out to be out of bounds, the trick is then to have a loop body like this: if (potentially_illegal_bit == 1) { load_legal_location_1() } else { load_legal_location_2() } After the branch misprediction occurs, the state of the program gets rolled back so we don't know what potentially_illegal_bit itself was anymore, but we don't have to, we can surmise it from the cache contents. The program isn't going to do an illegal read, it's going to do a legal one, to either legal location 1 or legal location 2, and see which is faster (as only one of them should be cached). Both reads are legal and will succeed, so the only difference is the speed. We've now exfiltrated one bit of data from outside of your array bounds, but the only actually illegal read was speculative, which, as far as the CPU is concerned, is par for the course (predictions are wrong all the time), so no harm, no foul.
  • Pxtl 9y ago
    Ahhh, that's what I missed. I thought the "speculative execution" people were talking about was executing the tricks on the copied data after the illegal read. But not only that, the entire illegal operation can be fenced behind a speculative execution with a simple "if" branch. And illegal reads happen in that kind of context all the time because (for example) that's how every FOR loop ends. There's really two places where pipelining and speculative execution are causing this problem - the obvious one where the CPU is allowed to manipulate protected data before everything gets blown away (except cache loads of legal data, hence the problem), but a second one that means that reads of protected data happen all the time in normal branch prediction misses. When it happens in normal flow, you can't punish it by killing the process. Reading protected memory in a speculative branch isn't some digital "attempted breaking an entering" that you can clamp down hard on, it's totally normal behavior. I get it now, thanks.
• DSMan195276 9y ago
  > Why not kill the process instantly on a prohibited read, then? Do these prohibited reads happen too often to switch from "oh, that's okay, you can try again and do other stuff" to "the punishment is death"? It's an interesting question. The pedantic answer is that they technically do actually happen all the time, that's just a page-fault. However in the page-fault handler you could just check what address they were looking at (And we already do, since we have to decide if we need to map a page, or throw a SIGSEGV), so effectively you could block them by checking the address. But it's actually fundamentally a lot worse. On its own, meltdown might be preventable that way, but you can combine meltdown with similar patterns to the spectre exploit to achieve the meltdown exploit without raising the exception. The kernel then can't prevent this, because no exception is raised, so it doesn't actually know anything happened.
• cma 9y ago
  > CPU tried to clean up access of protected memory, but failed to properly account for a fun trick of caching. > [...] > Why not kill the process instantly on a prohibited read, then? Because it was the CPU that tried, not the process/software that tried. It only tried in a branch that wasn't ever to be taken. Say for instance you have a pointer to some memory and a flag telling whether it is an absolute pointer or a relative pointer. Your executable checks the flag and sees that it is an abosolute pointer, so it reads the memory at the address. But the 'else' statement that was never supposed to run speculatively runs and treats the pointer as a relative offset that just randomly happens to go into system memory. You can't kill the process because of this, because the program never actually tried to go into system memory, the CPU just speculatively tried, and speculated wrong.