Servo Meeting 2014-09-29

Reminder

Please update your status at: http://benjamin.smedbergs.us/weekly-updates.fcgi/

Agenda

New bors, better than the old bors (jack & larsberg)
Safety of DOM bindings (zwarich)
Reviewing SpiderMonkey upgrade (jdm)
Test harness improvements (zwarich)

Attending

jack, jdm, kmc, larsberg, cgaebel, pcwalton, azita, brson, zwarich, june0cho, yichoi, gw, Manishearth, mrobinson

Automation / bors

jack: Bors is back! After a semi-painful transition, we are at full operational capacity. Build cycles from r+ to landing is about 18 minutes. A couple of people are not on the reviewers list, but have been patched in. If anybody sees anything weird, please alert larsberg and myself. Recap: We are using the same version of Bors that rust uses. We were unable to make the Basho feature-ified version of Bors work. Over the weekend, those patches landed a build that had failed buildbot. I am working on a new Bors to replace ours, in order to avoid the GitHub polling API limits. Since it takes 3 actions to land a PR, it takes 9 minutes (3 minute intervals) to actually land something approved. The new one will be based on GitHub notifications to avoid polling and waiting. It should trigger builds and landing instantaneously. We should only have delays for building. There is a repo up called "nelson" where this work is going on. I will recruit people to help once it is further along. If we're lucky, Rust can use it as well.
larsberg: I've started work on an Android builder. If I turn it on it'll probably not be gating landings, but I plan to finish that up in a week or two.

DOM binding safety

zwarich: Are the only safety issues with the DOM bindings the issues of storing a JS in a data structure where it might not be found and where Root does not correctly model the lifetime of the shared data? Are those the only two issues?
jdm: I believe so.
zwarich: Cool! Is there something we could do to solve the Root on? We could root everything with a macro that initializes it...
jdm: It's so ergonomically bad! I tried that.
zwarich: I don't like having memory-unsafe DOM bindings and would like to avoid that :-) Hopefully we will get better bindings?
jdm: We have dynamic checks that fail if a root gets moved.
zwarich: In all cases?
jdm: AFAIK.
zwarich: Isn't is possible for a GC to occur before the dynamic check and trash memory?
jdm: That is true. Only comes into effect when the destructor runs.
zwarich: I do get the point that we should catch it via testing.
pcwalton: Custom lint? The EUB should tell you if things are moved in Rust. Just use the ExprUse visitor in Rust.
zwarich: It's also not completely clear to me... if you return a Root from the Root constructor, data in the Root is passed off to the GC, what makes that correct?
jdm: Currently, in Servo today it's not a problem because the GC doesn't know about them. In the upgrade, there is an init method, but we should be able to use the return pointer intrinsic instead.
zwarich: There's an intrinsic to ensure you get the address of the eventual return point? Are we guaranteed rustc won't move it a second time?
pcwalton: We just need to make sure Rust doesn't do that.
jack: Is there something Rust could add that would make this safe?
pcwalton: Rust doesn't do moves except in well-defined circumstances. We need to make sure Rust doesn't start doing things that it shouldn't.
jack: I don't fully understand the "ROOT" of the unsafety there :-)
zwarich: There's a problem with the lifetime constraint that you want on a root.You can have both 'a and 'b now, but you need to know that one of them does not live longer than the root itself. Other is that when we pass a pointer to spidermonkey on the stack, we can get in trouble. If we don't do the lifetime tracking, we could end up moving a root, which is not memory safe. As jdm mentioned, we can add a check to the destructor.
jack: When you talk about a move you're talking about the Rust compiler moving a Root from one stack slot to another.
zwarich: Yes. There is an intrinsic you should be able to use with Rust, though. Just worried about the overall safety.
pcwalton: Custom lint seems like the easiest way forward now.
zwarich: Just worried if it can't catch them all. But maybe it can check almost everything.
kmc: If we need a new kind of lint - like after translation - it's not too bad.
pcwalton: As long as it's after typecheck so you can run the EUB.

SM upgrade

jdm: I'm tired of sitting on it! I'm going to get at least one SM hacker to look at the details. I want to assign those and start the ball rolling.
jack: ms2ger was going to look over it as well? Need one more internally. Maybe zwarich?
zwarich: Darn! I guess I picked the wrong week to look at DOM stuff... guess I'm signed up.
jack: The way the agenda items are set up, it just looks like you were set up for this!
jack: Is there a timeline?
jdm: No, I need to get a commitment.
jack: What can we do to help with rebasing?
jdm: Do not touch rust-mozjs or mozjs.
jack: Let's not do that, then, to make this easier for him.

Test harness improvements.

zwarich: Every time I run tests and see hundreds of processes, I wonder why we can't have one testrunner process that runs them in sequence. It's what webkit and blink do.
pcwalton: Yes, too much overhead right now.
zwarich: At least webkit splits off 4 processes and runs them in parallel. Different for us because we have them in parallel, too, but avoiding the process create/destroy would be good. Obviously, what we'll find is that lots of tests will start doing weird things because we've never done that before, but hopefully we'll find bugs. Since we don't typically navigate bugs anyway...
jack: A first attempt would be to just use libservo and call run directly.
zwarich: Yes, definitely the best way to start and then go from there.

Dogfood

pcwalton: In terms of dogfooding, with the work we've been doing, especially with forms, we're almost there.
mbrubeck: Except chrome!
cgaebel: And we can't click links.
jdm: I think I fixed that in my forms PR!
pcwalton: It's hard to have an automated test for that.
jack: Yes, our screen shots are starting to look really nice of Servo.
pcwalton: Yes, just a few little layout bugs and features left until we can display more of the pages.
jack: Status of CSSOM?
jdm: I will keep working on it. Need to figure out what tests I can add. Each browser does something different, and the spec doesn't say anything.
jack: Example?
jdm: element.style.backgroundPosition... every browser decides whether or not it will round-trip the author value. Different between Blink, Webkit, and Gecko.
jack: Lovely!
pcwalton: Don't forget IE5/6/7!
jack: Any idea what the spec authors intended?
jdm: I asked. They said, "good luck!"
zwarich: Specs: now Choose Your Own Adventure books!

Security

kmc: Little worried about security for dogfooding. stb_image and one or two other major vulnerabilities.
mbrubeck: And don't sanitize fonts...
pcwalton: I'm not worried about somebody trying to p0wn Servo. Maybe I'll work on a sandbox for it. Or just go all the way to e10s Servo. I have a branch. It's not ridiculous.
jack: Part of me agrees - we're planning to replace stb_image with rust_image, but many are much harder. Like certificate checking, and that seems much more dire.
kmc: We're not going to be using it for dogfooding everything, but could use it for non-signed-in pages. But if we're doing plaintext HTTP, a corrupted image can be MITM'd and own the machine. I'm less worried about web security because we're not going to be running github web apps.
jack: But we're almost there with Github!
kmc: Well, we don't have cookies. I'm a little worried in general about the fact that we don't sanitize, respect same origin policy, etc. I'm nervous about those things, because people wouldn't target servo, but it would be trivial.
cgaebel: And horrible marketing.
kmc: Pre-1.0 fancy servo 0-days aren't a big deal, but it's still scary.
pcwalton: Big disclaimers on any test build. We can call out that we have known insecure parts.
jack: We want people to try to p0wn Servo for soundness bugs in Rust!
pcwalton: There will be some soundness bugs in Rust, but more likely people will just grab a bug from a dependency.
kmc: Or some of our unsafe code, like parallel layout.
pcwalton: I'd like to see someone try to weaponize races in parallel layout!
zwarich: We could also make Servo save no state between invocations so that we don't need to allow write access to nearly anything. Maybe a couple things with the OS, but we could start with Safari's sandbox profile and try to cut it down.
pcwalton: I have one! Servo.sb. Should be in the github history.
zwarich: Yeah, if you can't read or write any files, you're not going to get very far.
kmc: Any linux solution?
pcwalton: Nope.
zwarich: Most of them are distro/kernel-patch specific.
kmc: selinux/yama...
pcwalton: Could convert that .sb file to a bpf filter...
jack: Or distribute it in a docker container!
kmc: I guess that's what the cool kids do these days.
pcwalton: We would like to ship Servo.sb and seccomp.bpf on Linux, though. And it would start making our tests fail if people open random OS files.
jdm: There is a student project in the coming months to evaluate replacing stb_image with rust_image. It should provide what sort of perf numbers we should expect.
mbrubeck: When we have users, we will need to update SM more than every year.
jdm: VOLUNTEER FOUND!
mbrubeck: Yeah, it's the weakest link. If we don't update SM every 6 weeks, we'll be in trouble.
pcwalton: stb_image will be the least secure, but SM is the easiest.
kmc: We will have to do the full security shebang at some point soon.
mbrubeck: For now, we can just be Haskell: avoid success at all costs! More users will push this...
pcwalton: Right now, we want people who want to kick the tires on Servo and build excitement, not users.
jack: Let's put this on the workweek agenda. Get the full checklist we need before we can push out a dogfood build to externals. That should help inform what we need to do for the rest of the year.

Workweek

jack: Who is evens pan? We have a mystery guest on the servo workweek, but nobody knows who this is...
azita: Exciting that the group is going so much we don't know their names!
jack: jdm is also soliciting more NCSU students.
jdm: There is a page of the projects the teams of students (2-3) will be claiming and working on for the next couple of months. Please be nice! ( https://github.com/servo/servo/wiki/NCSU-student-projects )
jdm: There should be enough info on the items for them to get started with it.
jack: How did this happen?
jdm: Prof contacted us last year and we did a couple of projects, and they came back.
jack: Web canvas stuff from last year?
jdm: Yes. It's a grad level course.
azita: Any at the workweek?
jdm: No.
kmc: I can help with the Rust tutorial!
larsberg: We have some playpen materials that have been well-tested and are probably only seriously buggy now :-)
jdm: Please send them to me!
larsberg: Will do.

Incremental reflow

pcwalton: It should be coming soon!
cgaebel: It's hard! But I'm working on it.
jack: Bunch of PRs to atomize things in Servo. Are we going to land those?
pcwalton: I need to fix them up. I have trouble running WPT because it keeps looking for some weird executable that doesn't exist.
kmc: I've been working on converting namespaces to use Atoms as well.
pcwalton: Can you finish that first?
kmc: Sure, I need it to land the parser as well. I am using a newtype for the namespace as well, which should catch some of the simple cases.
gw: I tore the JS from the WPT tests to an isolated file to repro the failure you were seeing in your PR.
jack: WPT runner was running everything with GPU rendering, which causes mac problems. But if you pass -c (by updating wptrunner to 1.2) or patch the wptrunner files yourself (look for --hard-fail in the .virtualenv), it will work. Master should fix this, though.
pcwalton: OK.
jack: I found that during bors. It didn't cause a problem on Travis, but did on our Linode builders.