491089 - Support jsdbgapi.h stack inspection on trace

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Jason Orendorff [:jorendorff]]

We can read the fields from the rp stack.

This might not help the debugger much.  The goal is to fall off trace less, especially when "just passing through" xpconnect.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Blake, Jason was mentioning that this might let us do security checks without bailing off trace...

Comment 2

[Andreas Gal :gal]

Are these the API entry paths we care about?

extern JS_PUBLIC_API(JSStackFrame *)
JS_FrameIterator(JSContext *cx, JSStackFrame **iteratorp);

extern JS_PUBLIC_API(JSScript *)
JS_GetFrameScript(JSContext *cx, JSStackFrame *fp);

extern JS_PUBLIC_API(jsbytecode *)
JS_GetFramePC(JSContext *cx, JSStackFrame *fp);

extern JS_PUBLIC_API(JSStackFrame *)
JS_GetScriptedCaller(JSContext *cx, JSStackFrame *fp);

extern JS_PUBLIC_API(JSPrincipals *)
JS_StackFramePrincipals(JSContext *cx, JSStackFrame *fp);

Also, a shell test case would be super helpful if anyone wants to help.

Comment 3

[Boris Zbarsky [:bzbarsky]]

What the security manager wants, for what it's worth, is JS_FrameIterator and then JS_GetFrameFunctionObject, JS_GetFrameScript, JS_GetFunctionScript, JS_GetFunctionObject, and some operations on JSObjects...  I guess if it can get a valid fp that's all correctly filled in, it's set.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Andreas and I talked this over some and I mentioned that it's also possible to cache the result of "can this wrapper access the wrapped object" (for XOWs) in the object itself. When that's implemented, the first time through, we might bail off trace (if given a XOW for a given object) the first time, but the next time around, we would successfully stay on trace.

The other thing that I've noticed is that caps doesn't *really* care about the frame pointer, function object, and all that goop (except for enablePrivilege stuff, which we could simply not trace through), it cares about principals. So, if instead of having an API that allowed us to walk the frame tree, we had one that told us the principals of the running code (implementable in the interpreter by walking the frame tree, and easily implementable in the tracer because a trace is tied to a particular global object [inner window, I hope!] so easily baked into the trace) then we could do security checks without bailing off trace.

Comment 5

[Andreas Gal :gal]

Attachment: partial untested patch, for discussion only

This patch introduces fake stack frames, which represent the distance from the top of the native stack. All functions that take a JSStackFrame* have to either call leave tree and then convert the fake pointer into a real pointer, or derive the value directly from the JIT frame (i.e. FrameInfo->callee->script).

This approach is a lot more brittle than handing out actual JSStackFrame pointers. If cx->fp changes, the numbering is invalidated. I am not sure whether the API makes much sense in that case anyway. cx->fp could be popped, for example. Brendan, what do you think?

Comment 6

[Jim Blandy :jimb]

Is this bug still relevant? The way we do wrapper security checks has changed a lot, hasn't it?

Comment 7

[Andreas Gal :gal]

Yeah, we are getting rid of stack walking altogether.