3 ms·

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 atta

by jkabrg 8y ago

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 8y ago
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.)
mannykannot 8y ago
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.

by jkabrg 8y ago

exikyut 8y ago

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

mannykannot 8y ago

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.