Skip to content

Workweek js bindings status

Jump to bottom
jdm edited this page Nov 11, 2014 · 1 revision

Servo security bugs & rooting

  • zwarich: Is it clear that we can actually root objects safely?

  • pcwalton: Not sure.

  • mcc8: Today, we use a static analysis in GCC to see if the objects are properly rooted across calls that can GC. In some perf-critical cases, you can't root everything. Can you track it in a type system?

  • zwarich: Also, returning from a function you have to return a raw pointer.

  • jdm: One thing about the SM upgrade is that we don't have an assembler pass.

  • pcwalton: Why not root everything?

  • zwarich: Perf.

  • jdm: Rooting is what you need to do, but need to make sure you don't leave around pointers to JS types (more of a problem in Gecko since they don't return equivalent of Temporary).

  • pcwalton: If people are saying you can't root everything because it's bad for perf, that's terrifying.

  • zwarich: You just can't statically check that you can interact with the GC right. Even using a conservative GC doesn't solve the problems.

  • dherman: One question is about the Azul patches for GC in LLVM. Is it coming?

  • zwarich: It's definitely landing. It's been in review for a couple of months, and the point of the talk at the LLVM dev meeting is that it's going to land. Using it for JS is easier than arbitrary rust stuff. JS doesn't have sum types and stuff that isn't supported by the LLVM/Azul patches. There are still some tricky problems with having a hash table keyed on JS values. The Azul stuff doesn't deal with that because everything is written in Java in their model.

  • pcwalton: Use the SM dynamic rooting stuff where Azul can't guarantee it? e.g., for hashmap insertion? Then we could still use JS for all of that. Then I could see a static analysis that ensures JS objects are always in things Azul knows how to handle.

  • zwarich: Given that there are still SM holes, the static analysis is probably not sound.

  • pcwalton: We control the language more. We should be able to make something sound.

  • zwarich: The global heap invariants (e.g, shape) are really tough for a static analysis tool to capture.

  • pcwalton: We just use JSAPI in the DOM code.

  • zwarich: Just our use of the DOM? Or the runtime parts of SM, too?

  • pcwalton: Maybe: how much of the SM runtime could be written in the JSAPI?

  • dherman: The perception, at least a while ago, was that it was a huge performance hit to use the public JSAPI internally.

  • pcwalton: Wonder if it's fixable. Also, is it true for some subset of the APIs? Sounds like we could (ignoring the perf problems) reduce our security problems by implementing JSRuntime objects using the JSAPI and then building a wrapper/analysis that enforces that we use it correctly.

  • dherman: Zooming out, that's lower priority than the other stuff on the agenda for Servo.

  • pcwalton: My reason for bringing it up is that if we're punting on SM fixes, maybe that's bad.

  • kmc: Also interesting to thinking about SM features implemented in Rust.

  • dherman: Good to keep in the back of our minds, but the first thing we ship Rust with will have enough annoying issues related to non-technical issues that we should have something trivial.

  • pcwalton: Should probably be image decoders.

  • zwarich: Bitmaps, TIFFS, ico files, etc. that aren't perf-sensitive is probably the best bet. Maybe NSS, if you're really ambitious. It's trickier because the things the code does has security implications.

  • dherman: With NSS, we want to be not involved in the politics, or code reviews, or other stuff related to security. We also really want our first couple of projects to be super likely to be successful. Ideally, it would have better security and performance to make it easier to land.

  • kmc: Yes, I want to avoid just rewriting things in Rust "because."

  • dherman: A fully correct implementation that's better for perf is a better sell than it's "about the same" and ambiguously secure.

  • kmc: I think that for UTF8 content, our new parser could beat Gecko's parser.

  • dherman: Good, but maybe not the first one. The parser is so key to everything Gecko does.

  • zwarich: Also, the correctness and benefit of Rust is around guaranteeing that it's memory-safe. In TLS/NSS, there's also a correctness issue for the security.

  • dherman: Decreased line count would also be a win.

  • kmc: That's easy to beat with the autotranslated java code for the HTML parser.

  • dherman: Also, there's support from hsivonen for that, right?

  • kmc: Yes, I want to chat with him at the Dec. workweek.

  • pcwalton: about:blank also has special semantics that require the secret second HTML parser inside of Gecko.

  • simonsapin: It has to do with window.open and document.write.

  • pcwalton: Might just be hard to replace the about:blank HTML parser because that's NSDocShell interaction stuff. OTOH, you could make your parser emit exactly the same old code...

  • mccr8: I thought they got rid of it recently...

  • pcwalton: Nope, it was on the "worst code in Mozilla" thread last month.

  • pcwalton: Returning to security bug audits, can we do that?

  • jdm: Roc's quote is old at this point.

  • larsberg: How can we do this audit? Can jack or I ask for the permissions?

  • all:

  • mccr8: Talk with Dveditz about the right way to do it. Look for bugs with sec-high and sec-crit, and keywords for type (sectype-uaf, bounds, etc.)

  • pcwalton: Do they ever make those public?

  • mccr8: We're not very good at it.

  • pcwalton: Maybe we could prepare and run a specific query...

  • mccr8: That might work.

Clone this wiki locally