Oo7: Low-Overhead Defense Against Spectre Attacks | Hacker News Reader

Oo7: Low-Overhead Defense Against Spectre Attacks

arxiv.org

80 pointsingve10 comments

>It is, however, possible to repair Spectre vulnerability without any performance overhead. In particular, oo7 quantifies the leakage (cf. Section 4.2.5) to investigate the range of memory touched by an attacker.

Maybe I missed it but how much padding is needed? Depending on how much, surely that isn't too bad of a compromise? Also wouldn't you have to randomise the amount of padding needed?

For the other methods the ~2% figure in performance loss also seems pretty decent.

Could someone explain to me how this would work for a (bytecode) interpreter?

I'm thinking a few thoughts:

  - Interpreted programs can carry out Spectre attacks
  - Interpreted programs are un-analysable using a technique that does binary analysis
  - This technique would insert fences "everywhere" in an interpreter, adding significant overhead

[edit]

I'm thinking it matters a lot whether the analysis is done at run-time or static. If the analysis is static, and it was done on the Python interpreter for instance, it would have to be very pessimistic. But if it's done at run-time, it might not need to insert as many "fences".

Well, I guess it wouldn't, because you're right, the fences would be "everywhere"; if one of the fences ends up in a hot path or inner loop, there goes your performance.

I don't know how oo7 works (I have admittedly gone straight to the comments on this one ;) ) but I do suspect it would be quite the ask (read: NP-hard) to expect it to identify interpreter{s, hot paths}.

However, if it's a JITing interpreter, that's technically compilation, and now the question is, how long does oo7 take to do its thing, and can it fit within JIT passes?

(NB. For clarity, choice of interpreter code architecture (bytecode vs anything else) is not especially orthogonal here, but the meaning is no less clear.)

The claim is that this mitigation avoids putting fences everywhere, and it is not clear to me that the performance hit on an interpreter's own code would necessarily be worse than for any other binary. I would guess the specific additional issue for interpreters is any sequence of instructions it creates dynamically (e.g. JIT compilation) and then has executed, and whether the interpreter provides the means (either intentionally or through a bug) for the attacker to influence that code generation such that it tests an address that the attacker should not have access to.

I would guess that any program, whether interpreted or compiled, that is capable (again, either intentionally or through a bug) of generating instruction sequences and then having them executed, could be used to exploit Spectre. This would include any program capable of writing a binary file and then running it as a process or dynamically loading it as a library or native-code extension, if allowed to do so by the OS.

Interesting. I'm mostly not tracking these since there is a ton of CompSci work post-Meltdown/Spectre. I do periodically look for things that try to stop many attacks at once. Here's two I found that were interesting with one in hardware and one for clouds on top of a verified hypervisor:

https://arxiv.org/pdf/1703.07706.pdf

https://pdfs.semanticscholar.org/6aa3/18e95cae5a932e330857e5...

One of the best binary analysis I've read. However, I stopped after "Inserting NOP instructions".

Why do you think Inserting NOP instructions will not work?

Current superscalar processors can skip over multiple NOPs at once.

I think it does not matter, skipping means the CPU does not execute it, but it still has room in RoB which is enough for defending Spectre. see this article: http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/

1. You do not reduce an overhead by creating another overhead. 2. Aren't the 'NOP' inserted making the read easier for the code to be reversed ?

Reply on news.ycombinator.com