Reply to post: Re: "but the basic problem is that chip designers traded security for speed. "

Data-spewing Spectre chip flaws can't be killed by software alone, Google boffins conclude

ChrisPVille

Re: "but the basic problem is that chip designers traded security for speed. "

I don't think Spectre is really the fault of the MMU. It's more that the caches are leaking program state via the side-effects of speculated instructions and other processes can infer that state with careful timing analysis.

The article hints at the hardware solution to this problem, which could be something like tagging cache entries with a process ID to ensure they won't be accessible from another process. It might also be possible to hold pending cache entries from speculated loads separate and not commit them until the instruction graduates. Either way, it's not a simple software fix. The processors in question all violate their own programmer's model, that is speculation will have no visible side-effects.

You're right that Spectre does look a lot like the timing and information leak attacks used against embedded devices, and while Spectre targets most speculating CPUs, I hope people who use caches in general are now carefully considering what could go wrong from a security perspective.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon