Robert O'Callahan wrote:
On Thu, Jul 12, 2012 at 7:08 AM, Brendan Eich <bren...@mozilla.com
<mailto:bren...@mozilla.com>> wrote:
Unsafe native code is one issue, but bugs in the smaller TCB of
the Rust compiler and runtime that compromise CFI could still be
exploited, fully in our experience in Firefox and other
Gecko/SpiderMonkey-based apps.
So I wonder whether, independent of what we do about enforcing CFI
in unsafe native code linked into Servo, we'll want to enforce CFI
in the Rust compiler and runtime. I don't think anyone has had
time to look into this, but it seems like a good research project.
Many interesting options have been explored, such as certifying
compilation, where the compiler generates along with the object code a
proof that the safety properties of the source language have been
preserved by that run of the compiler. That proof can be typically be
verified by a very simple proof-checker. I suspect doing this for the
Javascript compiler, where the attacker controls the input source
code, would be more important than for the Rust compiler, where the
attacker doesn't control the input source code so they only get to try
to exploit Rust compiler bugs that were actually triggered during a
particular Servo build.
I'm more concerned about runtime bugs -- the usual free memory read
during a virtual call. Rust will have vtbls, IIRC, and it takes only one
rooting or refcounting bug to enable an attacker to reclaim the live
object's vtbl. At least, this has been the bane of browsers' existence
for over seven years.
I don't think adding levels of sandboxing or verification to Servo
will be important anytime soon, though. Those are orthogonal problems
that are only worth solving once we have a browser engine worth
defending, and can be readily solved at that point.
The topic already came up, and the NaCl issue was filed. I honestly
don't know when we should get into this level of Servo security, but
"adding Security later" is an anti-pattern. I don't believe we can use
NaCl targeting Pepper in Servo, for instance. Seems worth a discussion
up front, even if we defer.
/be
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
