"Unless proven otherwise, ability to generate and run machine code, especially in same execution/privilege context as generator, is blatant memory unsafety comparable to the memory unsafety of C."
-
Show this thread
-
Replying to @RichFelker
as an extremely avid rust fan, i really agree that JITs are huuuuuge holes in language security models i think that rusts type system could help one write a maybe-correct-by-construction JIT, and there are JIT approaches that could be made less terrifying with beefy proofs...?
2 replies 0 retweets 2 likes -
Replying to @__anp__ @RichFelker
i’ve been interested for a while in the idea of porting a language runtime to emit its JIT code as webassembly that could be verified and compiled in a separate address space
1 reply 0 retweets 1 like -
Replying to @__anp__ @RichFelker
My feeling is that the best shot we have is layering: lower all the complexity of your source language to an IR that’s simple enough you can verify the correctness of a compiler for it (perhaps via Coq or something, though one probably doesn’t need to go that far).
2 replies 0 retweets 2 likes -
Replying to @pcwalton @RichFelker
However, the hard part of this is making sure the compiler is fast enough to be competitive. The trajectory of JS is unfortunately in the direction of fewer IRs and fast “hand code assembly for every macro-op”, for speed.
3 replies 0 retweets 1 like -
Replying to @pcwalton @RichFelker
i’m particularly interested in wasm for this IR, idk if that’s silly
1 reply 0 retweets 0 likes
It’s not silly, but the GC story is the hard part.
-
-
Replying to @pcwalton @RichFelker
i have had some thoughts on this but agreed v hard and probably requires some additional integration work beyond just changing machine code
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.