News for hackers. Stuff that matters.

A comment on Google: Software is never going to be able to fix Spectre-type bugs.

Re:Google: Software is never going to be able to fix Spectre... by pmoriarty on Saturday February 23, 2019 @11:50PM (#19237187)
"With careful construction, an attacker can make the processor speculate based on some value of interest and use the cache changes to disclose what that speculated value actually was. This becomes particularly threatening in applications such as Web browsers: a malicious JavaScript can use data revealed in this way to learn about the memory layout of the process it's running in, then use this information to leverage other security flaws to execute arbitrary code. Browser developers have assumed that they can construct safe sandboxes within the browser process, such that scripts can't learn about the memory layout of their containing process. Architecturally, those assumptions are sound. But reality has Spectre, and it blows those assumptions out of the water."

So this is yet another reason to avoid Javascript.

[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by lallysingh on Saturday February 23, 2019 @11:52PM (#19237195)
Couldn't the CPU maintain a few speculative cache lines that commit to regular cache if the speculation worked, and dump if not?

This would keep the L1 clean, at least

[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by amluto on Sunday February 24, 2019 @12:17AM (#19237261)
Yes, but it wouldn't help enough. For example, a speculative load from one core can observably evict or change the state of a cacheline on another core.
[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by lallysingh on Sunday February 24, 2019 @12:26AM (#19237286)
That seems to require a much more sophisticated attack. Also my point is that a speculative cache would be a separate (like a peer to L1) cache, only showing its side effects in L2/3. That'd be a bit harder to crack with the shared core noise and larger size.
[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by simcop2387 on Sunday February 24, 2019 @01:08AM (#19237380)
The problem with that is, what happens when your speculative code changed values in that region of memory that another core just wrote to. who wins? and how do you do it without now violating a bunch of other problems where one core sets up a memory fence and other things like that. It ends up incredibly complicated to decide what to do with the result that it's probably not worth the extra work.
[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by lallysingh on Monday February 25, 2019 @06:45AM (#19244907)
Why not ask the folks who did TSX?
[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by hylianwarrior on Sunday February 24, 2019 @12:31AM (#19237298)
It's not _just_ JS though...
[ Parent | on HN ]
Re:Google: Software is never going to be able to fix Spectre... by pmoriarty on Sunday February 24, 2019 @12:50AM (#19237336)
It's probably by far the largest vector for untrusted code in the world.

If its sandbox guarantees are broken by Spectre then the case for allowing it to run on one's machine becomes much weaker.

[ Parent | on HN ]