
Oo7: Low-Overhead Defense Against Spectre Attacks - ingve
https://arxiv.org/abs/1807.05843
======
foxes
>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.

------
jkabrg
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".

~~~
exikyut
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.)

------
nickpsecurity
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://arxiv.org/pdf/1703.07706.pdf)

[https://pdfs.semanticscholar.org/6aa3/18e95cae5a932e330857e5...](https://pdfs.semanticscholar.org/6aa3/18e95cae5a932e330857e5c8268a2218e191.pdf)

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

~~~
terminator_t600
Why do you think Inserting NOP instructions will not work?

~~~
anticensor
Current superscalar processors can skip over multiple NOPs at once.

~~~
terminator_t600
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/](http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/)

