Hacker News Reader

Comment by nhaehnle | Hacker News Reader

That's a good point.

Ideally the ISA would allow user level code to also toggle a flag that affects the BTB. That would allow embedding JIT code while guarding against Spectre 2 (fixing the BTB injection).

I don't think you really need more than that though. Reading arbitrary memory would seem to require a Spectre 1-type attack instead. Unless you have an explicit counterexample in mind?

For the JIT'ed code, Spectre 1 can probably be mostly avoided using the bitmask trick or something equivalent, which we seem to be moving in the direction of anyway (thinking about the WASM execution environment specifically), and for the "host" code inside the sandbox, the same kind of selective software fixes are required as in the kernel.

View on HN

I suspect you can get arbitrary memory read with Spectre 2 as well; just have to find the right gadgets. Which in a big program of the sort that would have a sandbox inside is somewhat likely...

(I can't comment on specific counterexamples in more detail than that, even if I know of any.)

I don't see how that could be.

Spectre 2 is about code in a less trusted domain A introducing an otherwise impossible branch target used by branch prediction on code in a trusted domain B. So a solution that adds tag bits to the BTB to distinguish between those domains should be a 100% effective fix. The only arguments are about how many tag bits & who gets to set them, i.e. a user-mode JIT sandbox would want to be able to control at least one tag bit for this, but if it can, it'd be fully effective.

Unless you start thinking about protecting different JITted code domains in the same address space from each other... I guess at some point you just have to bite the bullet and invalidate the BTB.

I suppose an additional problem would be if the BTB just "hallucinated" random indirect branch target destinations somehow, which could allow untrusted domain A code to jump (in speculation) to code that would normally be unreachable. A kind of "reverse Spectre 2", if you will, although the same tag approach should fix that at the same time as the original Spectre 2.

Spectre 1 attacks from JIT'ed code against the outside code are definitely possible though.

> The only arguments are about how many tag bits & who gets to set them

That's fair. I guess I've seen no indication that bits will be provided by ISAs and OSes to userland (past the bit that distinguishes userland from kernel code)...

> Unless you start thinking about protecting different > JITted code domains in the same address space from each > other

That's also fair. As a browser developer, this is my world right now. ;)

Reply on news.ycombinator.com