----- Original Message ----- > https://github.com/servo/servo/wiki/Workweek-alt-js > > I'm pleased with the "Table discussion until mid 2015" outcome :-). > > It might make sense at some point to have a "super secure Servo" build > where you plug in a JS interpreter and simple GC written in Rust, but I > can't see a viable general-purpose browser without a complex multitier JIT. > > In the long term, we should be able to have that plus security by > translating SM into Rust and introducing some kind of TAL/PCC safety > checking of generated code, maybe with some offline theorem proving for > critical bits like GC. The state of the art in this area is advancing > reasonably quickly. But I can't see any "rewrite the JS engine" project > making sense for Servo even in the medium term unless the landscape changes > dramatically (e.g. massive quantities of new resources fall from the sky).
From the JS engine bugs I've seen flying by, they mostly seem to involve violation of the internal invariants of the representation of the JS data structures, say, rather than buffer overflows or UAFs, so I don't know how much Rust would help improve the security story there. If anybody wants to get a sense of some of the bugs in the JS engine, search on bugzilla for bugs with sec-high or sec-critical keywords that have a resolution of FIXED and are assigned to bhackett. When he attaches patches to bugs, he usually includes a nice description that at least gives you a sense of what is going wrong. For instance, from bug 842424: "There was a missing use of newKind that caused 'new' objects which are supposed to have singleton type to not have singleton type. Their properties were then cleared, causing them to go out of sync with their type information --- they were marked as definitely having properties when they actually didn't have any, and Ion invoked a pre barrier on a slot of the object which did not correspond to any property, which in debug builds is a poisoned ObjectValue(42)." So I'd say that given all of the engineering work it would take to get a vaguely competitive JIT a better use of time would be an experiment to add some more dynamic checking (like PCC/TAL) to SM. One fun property of PCC/TAL is that you don't even have to run the produced code in order to find errors, which is particularly nice if you are looking for things like errors in array bounds checking elimination where hitting a case that does something bad could be tricky. It might really increase the efficiency of fuzzing per CPU hour, though I'm not sure if anybody has ever tried to fuzz a PCC/TAL compiler before. Andrew > > Rob > -- > oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo > owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo > osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo > owohooo > osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o > oioso > oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo > owohooo > osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro > ooofo > otohoeo ofoioroeo ooofo ohoeololo. > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
