Re:V8: A Year with Spectre
by monocasa on Tuesday April 23, 2019 @02:16PM
(#19731301)
Even if the untrusted code is in another SIP, if it was susceptible to Spectre you'd be able to break down that boundary.
[ Parent
| on HN ]
In Singularity, the system gets to decide what happens at SIP boundaries (and the kernel ABI boundary).
HIP is the full address space change, but any mitigation steps can be introduced in the IPC hand-off between SIPs (or at the kernel ABI) compiled into the untrusted process. This code is compiler controlled. The system is in ring-0 so IPC code gets full access to available instructions (such as mitigation is possible there).
Of course doing this makes channel communication in both directions slow for untrusted processes, but that is the cost of doing business with Spectre. And if someone wrote a browser that didn't use channels for talking to the JS engine, then all bets would be off.
With Spectre, malicious processea doesn't need to have code execution cross a SIP boundary in order to break confidentiality of other colocated SIPs. As a malicious SIP, I can just read out the rest of the hardware visible context.
How does the hardware visible context get suitably updated if the confidential data in the other SIP isn't touched by execution (speculative or otherwise)? Doesn't something need to be pulling that state into the visible context?
As far as the hardware is concerned, the confidential information in the other SIP is already visible.