Re:How a researcher hacked his own computer and found 'worst...
by cma on Thursday January 04, 2018 @04:28PM
(#16074240)
> 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.
> [...]
> 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.