| 17:10 | <Michael Ficarra> | Michael Ficarra: the most chrome / v8 bugs are not because our C++ is doing memory management wrong, they are because we have a logic bug in generating machine code or because our invariants are extremely complex and one part might make a change which violates an invariant somewhere else. happy to talk more about this. interestingly, a huge proportion of the CVEs listed on shu's slide were in my code, and none of my bugs were because of C++, and would've happened even if V8 was written in a memory safe language. |
| 21:00 | <shu> | i'm not sure why there's a connection between partial evaluation and the heap sandbox? |
| 21:01 | <shu> | the thesis of the article is that because graal partially evaluates an interpreter, this class of bugs is avoided |
| 21:02 | <shu> | but a heap sandbox is about protecting memory representation being exploited by an attacker, which can arise from type confusion bugs due to JIT bugs, but can also just arise through other vectors |
| 21:04 | <shu> | a partial evaluator doesn't avoid that by construction. it can avoid some of the attack surface, though, and is a cool technique |
| 21:07 | <shu> | the heap sandbox would need to exist at the JVM or the native codegen layer in the GC runtime if you're bundling a GC, not really at the compilation layer. the graal thesis still requires that your interpreter is correct, or all the object runtime code that deal with actual representation of your objects are bug-free, right? the point of the heap sandbox is that it's another containment layering assuming that the VM is already pwned, which is... closer to reality imo |
| 21:08 | <shu> | also caveats about "without sacrificing performance" which seems to be about peak performance yada yada yada |
| 21:18 | <Michael Ficarra> | yes, see this quote:This architecture is standard — both the JVM and V8 use it — but viewed from a security perspective the design has a flaw: it’s error prone. The language semantics are implemented twice, once for the interpreter and again for the JIT compiler. It’s critical not only that both places are fully correct but also that they exactly match. Otherwise, the VM becomes exploitable. |
| 21:19 | <Michael Ficarra> | assuming you have a correct interpreter, you don't have a second implementation (the JIT) which introduces its own bugs or just differences in behaviour |
| 21:27 | <shu> | but that's a narrower class of bugs than the heap sandbox is designed for |
| 21:28 | <shu> | i.e., the heap sandbox is defense in depth assuming several class of bugs. this blogpost is saying, our technique can sidestep one such class of bugs |