981623 - JitRuntime: Ensure that JitRuntime stubs are compartment-independent.

Status: NEW

(Core :: JavaScript Engine: JIT, defect, P5)

Description

[Nicolas B. Pierron [:nbp]]

Currently we distinguish JitRuntime and JitCompartment[1, 2].  A JitRuntime contains stubs which are useful for all generated code within one JSRuntime.  A JitCompartment is like a compartment, it only contains code which is safe within the current compartment.  So, we want to use the JitRuntime as much as possible, except when we are dependent on the compartment.

A simple way to see if we depend on the compartment is if we are referring to the any of zone / ImmGCPtr within the macro assembler.

Such check can be done in the Linker.  In which case we can make a new type of JitCode, named JitSafeCode/JitStub which are checking these invariants.  If the assertion in its linker are ok, we can then move the stub to the JitRuntime instead of keeping it in the JitCompartment, or the inverse.

By adding such class we would have a simple rule for doing such segregation, and assertion & naming-scheme will prevent adding security/privacy issues.  (the naming-scheme would be that JitCompartment has all JitCode and JitRuntime has all JitSafeCode)

[1] http://dxr.mozilla.org/mozilla-central/source/js/src/jit/JitCompartment.h
[2] http://logbot.glob.com.au/?c=mozilla%23jsapi#c362647

Comment 1

[Brian Hackett [Laid off!]]

(In reply to Nicolas B. Pierron [:nbp] from comment #0)
> A simple way to see if we depend on the compartment is if we are referring
> to the any of zone / ImmGCPtr within the macro assembler.

How exactly would this check work?  Internal pointers to either the runtime, zone or compartment can be baked into jitcode and they are ImmPtrs and not ImmGCPtrs and which one a given pointer is dependent on is not readily distinguishable.

Why not just ensure that JitRuntime code stubs are never created with access to a meaningful compartment/zone, as is currently done in JitRuntime::initialize (cx->compartment is the atoms compartment, which code never runs in).

Comment 2

[Nicolas B. Pierron [:nbp]]

(In reply to Brian Hackett (:bhackett) from comment #1)
> (In reply to Nicolas B. Pierron [:nbp] from comment #0)
> > A simple way to see if we depend on the compartment is if we are referring
> > to the any of zone / ImmGCPtr within the macro assembler.
> 
> How exactly would this check work?  Internal pointers to either the runtime,
> zone or compartment can be baked into jitcode and they are ImmPtrs and not
> ImmGCPtrs and which one a given pointer is dependent on is not readily
> distinguishable.

Then we can make a ImmCompPtr, which only accept compartment pointers and only offer thecoercion in exchange of setting a flag on the Macro Assembler.

ImmGCPtr are listed in the list of relocatable area in order to be marked, so asserting that this list is empty should work.

> Why not just ensure that JitRuntime code stubs are never created with access
> to a meaningful compartment/zone, as is currently done in
> JitRuntime::initialize (cx->compartment is the atoms compartment, which code
> never runs in).

Do we have a simple idiomatic way to check that every methods which is generating code has such property?

A simple way to enforce something is to make it the only option.  Switching the field type is creating an idiom which is easy to follow and add burden when people are trying to do their favorite copy & paste pattern.

Then, I do not care how we enforce such property for getting an IonSafeStub.