The (three differnet) Intel flaws rely on "speculative execution". As the CPU executes both possible execution paths after a branch, the incorrect path's work is not "committed". Intel's fetch protection is only raised as each instruction is committed. As a result, you can fetch protected memory, and load other (unprotected) memory to a register depending on whether or not the contents of the protected memory were a certain value. Everything you loaded disappears as the branch target is resolved with certainty, but the (unprotected) memory you fetched is now in cache. If you fetch it again you can time whether or not it was in cache, showing you if the "speculative execution" loaded the piece of unprotected memory or not, effectively leaking the contents of the protected memory.
The other one relies on the same principle, except you perform speculative execution during out-of-order execution of instructions. You let the CPU perform work when you know that X instructions earlier, you're going to receive an exception. So you handle the exception, and the out-of-order instructions that were already executed are rolled back, but can leave traces in cache. While unlikely, it's not unthinkable that z/Architecture is susceptible to a similar attack. It all depends on when the CPU raises the protection exception. Do the pipelines of an unresolved branch stall as soon as an instruction fetches protected memory? Or is it raised as the CPU tries to commit the pipeline's work? If a similar attack works, as long as it's addressable, you can read it. I do not exactly know where the DAT tables live, and if they, or the real address they reside at are in fetch-protected common storage, you could get a hold of them. But regardless, I do not believe you can read using real addresses without executing privileged instructions at some point. We'll most likely never find out whether or not this flaw exists on z/Arch, as IBM is going to patch this. I'd try it out but I have neither the time nor the hardware. - Jan ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
