Re: [dev-servo] More planning
On Thu, Feb 14, 2013 at 7:19 PM, Luke Wagner wrote: > > Eventually I can imagine writing the JIT in Rust and using some kind of > certified > > compilation to guard against compiler bugs. > > I haven't really followed this topic; do you really think this would be a > feasible approach to a production JS engine? I appreciate that we'd only > have to certify that the jit code was safe, not correct, but that still > doesn't seem significantly easier given the complexity of jit techniques > required to achieve competitive JS performance. > I haven't kept up with the state of the art, but I guess it's feasible with "enough" effort, using a combination of static theorem proving and online verification. For a fully sound system the hardest part might be proving the correctness of GC. It's fair to question whether this is really something we should depend on. On one hand, it's research, on the other hand, technology in this area is improving pretty rapidly. IIRC for Singularity/Midori Microsoft has verified type safety for the entire stack down to the machine code (that's a static compiler, not a JIT, and C#, not JS ... but C# is hard in its own way). I'm more confident that someone will eventually be able to do this than that we'd be able to do it in any given timeframe. > For now, just get it right :-). > > It seems like a scary-large proportion of security sensitive bugs come out > of the JS engine (and it's not because we don't care :). > I thought layout was that scary-large portion :-). > > Sure, the JS JIT will have to be part of the TCB for now. > > If the certified-compilation scheme doesn't work out (this eventuality > seeming rather likely IMHO), it seems like making this TCB assumption early > on would lead us to make some bad architectural decisions that would be > difficult to fix later (a story we know all to well :). > True, but there is also a danger that fear of being architecturally boxed-in causes us to do something over-elaborate :-). I have the impression that the non-JS part of the Web platform grows at a much faster rate than the JS part, and lots of the JS part doesn't even need to be in the TCB. So I hope the proportion of sec-sensitive JS bugs goes down. Maybe. I wonder whether it would make sense to provide process separation and sandboxing in the Rust runtime. Is there any reason why we couldn't identify clusters of Rust tasks and wrap them up into sandboxed processes, verifying message integrity at process boundaries? (Choice of process boundaries would be made manually, I'm not talking about crazy automation.) If that's doable transparently (in semantics, if not performance), sandboxed processes at whatever granularity desired could be retrofitted as needed without changing Servo code. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
Robert O'Callahan wrote: > I thought we were going to rely on Rust's > isolation mechanisms for this kind of finer-grained isolation. I > thought that was a big part of the point of introducing Rust in the > first place Let's make the assumption that some future web browser-like thing, intended for the general public to use as their everyday web access, will be based on Servo. I'm sure that these questions are FAQs, but I could not find the answers: 1. How much of that thing will be written in JS and the safe subset of Rust? What are the non-JS, non-Rust components that it would have? In particular, do we expect to rewrite all of the imported code that currently comprises browser like Chrome and Firefox, such as WebRTC, FreeType, sqlite, etc.? 2. What are the security goals for that first version of that thing? What is the end goal as far as security goals? 3. Will that thing support Flash or any other plugins? > true "process per origin" can't really scale to > large Web workloads because processes carry a lot of overhead, 4. What are the targeted minimum hardware requirements for the thing? 5. What is our model of the user's use of the thing? FWIW, not even the Chromium guys are trying "process per origin." Their current experiment is "process per site," where a "site" is same eTLD+1, e.g. *.google.com. Also, if you have 100 different sites open, that doesn't mean that you need to have 100 loaded processes, even in the process-per-site model. > but language-based isolation potentially can since the overhead > can be a lot lower. I thought that was a big part of the point > of Servo! I think there is no doubt that Rust on its own brings a lot of security advantages to a browser-like thing based on Servo. But, as the design document notes, there are things that Rust can't do. For example, Rust can't, in general, stop you from writing "if (!x)" instead of "if (x)" like I did in a recent NSS bug. > (Of course a big sandbox around the entire browser, or independent > browsing contexts, could still be useful as a second line of defense > to prevent the system from being persistently corrupted in case of a > Rust exploit.) I think access/modification of cookies, passwords, and other security-sensitive data within the browser will be (if not already) just as sensitive as access/modification of anything local to the computer for typical computer users. And, I think we can go further and say that the damage from allowing a violation of same-origin policy will approach (and, in some configurations, exceed) the damage done by escaping from a hypothetical whole-browser sandbox. Consequently, I think that we'd be best served by concentrating effort on guaranteeing the enforcement of same-origin policy (which subsumes protection of credentials and arbitrary code execution with the full rights of the user account running the thing based on Servo) in *some* useful way. I think there are several different reasonable alternatives for doing that, based on what our risk tolerance is in terms of security, and what our risk tolerance is in terms of overhead. I am very interested in, and supportive of, the idea that we can eventually write highly-secure, high-performance software without relying on sandboxing in the way that every other browser does it. Just, from all the things I've read and heard, it is very unclear that Servo will end up to be competitive in terms of security with competitors in a reasonable timeframe given a reasonable estimation of resources, especially if Google's process-per-site experiment is successful. That is why I think it is valuable to further explore how sandboxing could be used to increase security assurance and reduce risk for the project. And, my concern is that if we wait until after we've designed and implemented huge chunks of Rust, we'll find any work to attempt sandboxing to be a drag on the project, instead of an accelerant. Or, in other words, I think that if we have a good plan for sandboxing now, then there's a good chance that sandboxing could help us ship some thing based on Servo to r eal people faster. Cheers, Brian ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On Thu, Feb 14, 2013 at 10:49 PM, Brian Smith wrote: > 3. Will that thing support Flash or any other plugins? > Definitely not. I think there is no doubt that Rust on its own brings a lot of security > advantages to a browser-like thing based on Servo. But, as the design > document notes, there are things that Rust can't do. For example, Rust > can't, in general, stop you from writing "if (!x)" instead of "if (x)" like > I did in a recent NSS bug. > Sure, but so what? Neither process-level sandboxing nor any other technology we can lay our hands on will prevent that. I think access/modification of cookies, passwords, and other > security-sensitive data within the browser will be (if not already) just as > sensitive as access/modification of anything local to the computer for > typical computer users. > I totally agree. Just, from all the things I've read and heard, it is very unclear that > Servo will end up to be competitive in terms of security with competitors > in a reasonable timeframe given a reasonable estimation of resources, > especially if Google's process-per-site experiment is successful. > There are many large risks that may prevent Servo from being competitive in any timeframe, let alone a reasonable one. It's a high-risk research project. I hope we're all comfortable with that :-). I think it's premature to start making a roadmap that makes Servo a competitive product in N years; apart from anything else, such a roadmap is going to be pure fantasy when there are still many basic questions we don't know the answers to. But you're right, I was overly dismissive of granular process-level sandboxing. It's worth thinking about how it could be fitted into Servo if and when the need arises. However I still think there's a lot of very basic stuff, like how DOM and layout work, that is more important to work on. Rob -- Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On Thu, Feb 14, 2013 at 10:49 PM, Brian Smith wrote: > For example, Rust can't, in general, stop you from writing "if (!x)" instead > of "if (x)" like I did in a recent NSS bug. Depending on what 'x' is and how it was obtained it's possible it could be stopped. If it's a null pointer check for example then in Rust you'd be pattern matching on an option type and you wouldn't be able to use 'x' in the '!x' portion without a compile error. Depending on the evolution of Rust, if it's a boolean result that affects other arguments related to where the result was obtained, the types of those objects could be changed such that the code doesn't compile (dependent types, typestate or in the absence of that API design similar to Patrick Walton's 'Typestate is Dead' article). You're right about the 'in general' though. Sorry about the derail, but I'm generally interested in how Rust-like languages can help avoid these types of errors. Chris. -- http://www.bluishcoder.co.nz ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Codegen WIP
Patrick convinced me that I should work in public, so here's the branch in which I'm banging away at the bindings codegen: https://github.com/jdm/servo/commits/codegen . This is the current output so far: https://github.com/jdm/servo/wiki/Codegen-output I don't recommend attempting to reproduce this; I've got several outstanding rustc patches since my work tickles all of the dusty corners of constant expressions in Rust right now, and there are also various symlink and manual python invocations that I need to turn into make targets at some point. Cheers, Josh ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On 2/13/13 11:19 PM, Patrick Walton wrote: Servo now ships a known-working version of Rust, so it should be easier to build. OK. I've spent about 3 hours so far on that today. So far there were two build system bugs that had to get fixed just so that I could get out of configure, a non-building mismerge (apparently) that had been checked in, and a fix for the mismerge that didn't actually quite fix things. And now I'm to rust-cocoa/base.rs doing various unsafe stuff outside of unsafe functions/blocks. I'm going to take a break from this and try to get some of my other work done now. :( -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Codegen WIP
On 02/14/2013 05:18 AM, Josh Matthews wrote: Patrick convinced me that I should work in public, so here's the branch in which I'm banging away at the bindings codegen: https://github.com/jdm/servo/commits/codegen . This is the current output so far: https://github.com/jdm/servo/wiki/Codegen-output I don't recommend attempting to reproduce this; I've got several outstanding rustc patches since my work tickles all of the dusty corners of constant expressions in Rust right now, and there are also various symlink and manual python invocations that I need to turn into make targets at some point. Cheers, Josh Thanks, Josh. Your progress here is really encouraging. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On 02/13/2013 07:55 PM, Boris Zbarsky wrote:
On 2/13/13 10:16 PM, Boris Zbarsky wrote:
On 2/13/13 9:47 PM, Brian Anderson wrote:
I haven't actually created a DOM-related milestone yet because we
haven't come up with a goal that I'm satisfied with ("create working
dom
bindings" is vague). Things we've considered as short-term bindings
goals are canvas and WebGL. Does anybody have suggestions here?
How about deciding on an actual implementation strategy for the DOM?
Note that from this point of view canvas and webgl are uninteresting
because they have only one DOM interface involved, so there are no
inheritance issues and whatnot.
A basic binding for Node that allows JS to do .firstChild without a
virtual function call on arbitrary nodes would be a lot more like what
I'm looking for here.
I understand your concern and I agree that validating the architecture
is our primary goal. Thank you for raising the subject. It is the first
thing mentioned on the roadmap on the wiki, but I neglected to consider
it when putting together these milestones.
So as you suggest, maybe we should tie some performance goals to the DOM
implementation. I've started by creating a new milestone that includes
the `firstChild` test and the issues that block it:
https://github.com/mozilla/servo/issues?milestone=3&state=open
The main performance issues that you've expressed concern about and that
I can recall are in the following issues:
* FFI stack switching - https://github.com/mozilla/servo/issues/278
* FFI virtual calls - https://github.com/mozilla/servo/issues/278
* DOM representation - https://github.com/mozilla/servo/issues/280
* string representation - https://github.com/mozilla/servo/issues/282
* optimizing layout requests - https://github.com/mozilla/servo/issues/283
3 of those are on the list for the new milestone. The string and layout
issues are not. Do you think it is appropriate to make either of those
part of the milestones for this year? Are there other critical
performance questions I'm forgetting?
I hope this helps ease your mind somewhat, but let me know if otherwise.
For your reference, some of the performance issues you've raised
previously are already impacting Rust's design. Most significantly the
[FFI] is in the process of being redesigned to support servo's use case.
Also, the upcoming [scheduler] redesign should give us more
opportunities to experiment with optimizations relevant to servo.
Regards,
Brian
FFI: https://github.com/mozilla/rust/issues/3678
scheduler: https://github.com/mozilla/rust/issues/4419
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On 2/14/13 5:33 PM, Brian Anderson wrote: * FFI stack switching - https://github.com/mozilla/servo/issues/278 * FFI virtual calls - https://github.com/mozilla/servo/issues/278 * DOM representation - https://github.com/mozilla/servo/issues/280 * string representation - https://github.com/mozilla/servo/issues/282 * optimizing layout requests - https://github.com/mozilla/servo/issues/283 3 of those are on the list for the new milestone. The string and layout issues are not. Do you think it is appropriate to make either of those part of the milestones for this year? Are there other critical performance questions I'm forgetting? In terms of DOM bindings, no, I don't think so. I do think we should get our string story straight sooner rather than later, or at least make sure we don't start depending too heavily on it being a particular way.. I'd really hope we can do that this year. A far as optimizing layout requests, I think that's more tuning that will need to happen sometime, but isn't urgent as long as we can demonstrate that we _can_ do it fast enough in a microbenchmark. I hope this helps ease your mind somewhat Oh, my mind was at ease already, more or less, on the DOM bits. We can solve it; it's just a matter of timeframe... I'm more worried about strings and cross-task communication. For your reference, some of the performance issues you've raised previously are already impacting Rust's design. Most significantly the [FFI] is in the process of being redesigned to support servo's use case. Also, the upcoming [scheduler] redesign should give us more opportunities to experiment with optimizations relevant to servo. That's really good to hear! -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
