Reminder: all Spectre, except v1 style, should be fully fixable, without trusting vendor ucode updates to do it right, by flushing whole cache hierarchy at every kernelspace entry and exit and turning off HT. Anyone tried this and measured cost?
Running tasks sharing same vm space on both HT threads is no loss in protection if you only flush cache at vm context switch, but doesn't allow you to protect kernel memory from the user task.
-
-
So you'd need to halt the other thread in the pair when either entered the kernel.
-
Yeah. You could do it with IPI's but then you're just going to make syscall entry/exit even more expensive...
-
Except IPI between HT should be trivial?
-
Not any moreso than cross-core. The whole pipeline has to be flushed, the hardware and software sides of exception handling have to run, ...
-
An interrupt vector whose handler is the HLT instruction seems cheap enough for a quick stop. Resuming's slightly fiddlier...
-
If you do that I don't think it's resumeable. You would rather spin on a variable "while(sibling core is in kernel)" then ret-to-user. You also need to multiplex IPI with other kernel use of it, which brings in nontrivial kernel surface.
-
And somebody would signal() the HT while the other thing was in kernel and run exploit code in the handler... Needs HW support.
-
No, signals can't interrupt kernelspace except voluntarily via EINTR/restart. They're handled on return from kernel to user.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.