Presumably you could safely HT threads of the same process?
-
-
-
I don't think so. Security boundary is not just at ht these days. If your application is sandboxing the execution of something else like browsers do with js this is a problem.
-
Right, this is why I said except v1 style.
-
Presumably process could provide a HT ok flag, or disable it when call to mprotect or namespace or something? Hmmm...
-
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?
- 5 more replies
New conversation -
-
-
Not sure about flushing at every context switch, but doing so whenever a different process is scheduled on a CPU (or core complex, when a complex shares L2) might make sense because there's probably some amount of eviction happening in such cases anyway.
-
Every entry/exit is needed to avoid kernel leaks if you don't trust mitigations on kernel side. Otherwise just at vm context switch is ok.
-
It would be nice to see both tested and compared.
End of conversation
New conversation -
-
-
I wonder if flushing the TLB would be enough since L1 is physically tagged on popular CPUs
-
No, because you can look for evictions of your own cached data to determine what speculative accesses happened in the victim.
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.