Rowhammer does not defeat language semantics-based sandboxing mechanisms, because it requires settings up an anomalous instruction stream, with a very high density of cache-flush instructions; an AI could only do that if it had the ability to create and run new code for itself, bypassing your compiler.
But that’s exactly what Rowhammer.js accomplished! They POCd Javascript code that, given a certain Javascript compiler (JITter), causes binary code to be output that triggers Rowhammer. Thus it escaped the langauge semantics based sandbox.
As long as your compiler doesn’t deliberately avoid outputting binary code with a particular property (e.g. rowhammering), it might be possible to choose compiler input that will create the desired output.
Hmm. Papers [2] and [3] demonstrate an attack starting from a position of executing native code; [4] I didn’t read until just now, and that’s the one that works within Javascript’s semantics.
They had three test machines: a Sandy Bridge laptop, an Ivy Bridge laptop, and a Haswell desktop. The Sandy Bridge laptop seems to have only been used for studying its cache-eviction policy, they don’t report a result (positive or negative) for getting it to flip bits. They studied three memory-corruption strategies: in descending order of strength, clflush, evict (native), and evict (JavaScript). The first strategy (clflush) is the previously-discussed strategy using cache-flush instructions, which can only be done from native code with a highly unusual instruction mix. The two evict strategies work by making a pattern of memory accesses which interacts with the processor’s caching rules. The clflush version requires executing native code; the evict strategies work if the code is JITted.
All three strategies worked against the Ivy Bridge test machine. None of the strategies worked against the Haswell test machine. (They note that Lenovo released a BIOS update which decreases the memory refresh interval, which would likely make it resistant, which they didn’t test). They then went on to change the Haswell’s memory refresh interval in the BIOS settings, and compared the rate of bit flips with the three different strategies at different memory refresh intervals (figs. 4 and 5). The eviction-based strategies start causing bit flips at a refresh interval that’s slightly more than twice as long as the clflush based strategies; the native and Javascript evict-based strategies started producing bit flips at very close to the same refresh interval.
They did not build a root exploit out of the Javascript version, and to get bit flips at all, they used a modified Javascript interpreter which provides an inverted page table. This is a fairly substantial cheat. They think they could make a root exploit out of this, and I believe them, but the difficulty is quite a lot higher than the clflush-based version and it has not in fact been accomplished.
So to summarize—code running through a JITter is in fact at a large disadvantage when trying to exploit you, just not quite so large a disadvantage that you should feel invulnerable. Stepping back to the bigger picture, assuming RowHammer will be fixed but other vulnerabilities will remain, I expect that language semantics-based sandboxing will protect from many, likely most, but not quite all of them.
But that’s exactly what Rowhammer.js accomplished! They POCd Javascript code that, given a certain Javascript compiler (JITter), causes binary code to be output that triggers Rowhammer. Thus it escaped the langauge semantics based sandbox.
As long as your compiler doesn’t deliberately avoid outputting binary code with a particular property (e.g. rowhammering), it might be possible to choose compiler input that will create the desired output.
Hmm. Papers [2] and [3] demonstrate an attack starting from a position of executing native code; [4] I didn’t read until just now, and that’s the one that works within Javascript’s semantics.
They had three test machines: a Sandy Bridge laptop, an Ivy Bridge laptop, and a Haswell desktop. The Sandy Bridge laptop seems to have only been used for studying its cache-eviction policy, they don’t report a result (positive or negative) for getting it to flip bits. They studied three memory-corruption strategies: in descending order of strength, clflush, evict (native), and evict (JavaScript). The first strategy (clflush) is the previously-discussed strategy using cache-flush instructions, which can only be done from native code with a highly unusual instruction mix. The two evict strategies work by making a pattern of memory accesses which interacts with the processor’s caching rules. The clflush version requires executing native code; the evict strategies work if the code is JITted.
All three strategies worked against the Ivy Bridge test machine. None of the strategies worked against the Haswell test machine. (They note that Lenovo released a BIOS update which decreases the memory refresh interval, which would likely make it resistant, which they didn’t test). They then went on to change the Haswell’s memory refresh interval in the BIOS settings, and compared the rate of bit flips with the three different strategies at different memory refresh intervals (figs. 4 and 5). The eviction-based strategies start causing bit flips at a refresh interval that’s slightly more than twice as long as the clflush based strategies; the native and Javascript evict-based strategies started producing bit flips at very close to the same refresh interval.
They did not build a root exploit out of the Javascript version, and to get bit flips at all, they used a modified Javascript interpreter which provides an inverted page table. This is a fairly substantial cheat. They think they could make a root exploit out of this, and I believe them, but the difficulty is quite a lot higher than the clflush-based version and it has not in fact been accomplished.
So to summarize—code running through a JITter is in fact at a large disadvantage when trying to exploit you, just not quite so large a disadvantage that you should feel invulnerable. Stepping back to the bigger picture, assuming RowHammer will be fixed but other vulnerabilities will remain, I expect that language semantics-based sandboxing will protect from many, likely most, but not quite all of them.