Open Bug 1108262 Opened 8 years ago Updated 4 years ago

Audit use of AutoJSAPI and replace it when needed with AutoEntryScript

Categories

(Core :: XPConnect, defect)

36 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

REOPENED

People

(Reporter: smaug, Unassigned)

References

Details

I wonder if we could statically check that AutoEntryScript is used when needed.
It is hard to know if some JSAPI method might run script.
Boris thinks that, if we don't have an AutoEntryScript, we should unconditionally throw when entering APIs that _may_ run script (like JS_GetProperty), even if they don't actually run script in this case. That would make finding the problems much easier.

We probably need a simple JSAPI callback to ask the embedding whether it's allowed to run script.
Anything that may run script may also GC. So if we treated AutoJSAPI the same as we treat AutoCheckCannotGC, namely by pretending that it is an unrooted GC pointer, then we would get a rooting hazard anytime you called anything that could run script within an AutoJSAPI.

However, that would mean that if you were within an AutoJSAPI, you couldn't instantiate an AutoEntryScript and then run script. If that is something you're supposed to be able to do, then we could hack that into the analysis.

But also, anything that can GC will not necessarily run script. So if AutoJSAPI is used around JSAPI calls that might GC but will never run script, then this scheme won't work.

Still, this is close to what the analysis is already doing. If we could identify a full set of inner functions that run script, it would be fairly easy to set up a specific analysis for this case.

For manual auditing, I also have a callgraph traversal tool. It won't help if there are any function pointers that might (indirectly) call script. But that aside, you can ask for paths from function A to function B (where function B is your script invocation, and function A is... well, I suppose it's any function call within an AutoJSAPI scope, which you would need to gather manually.)
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
You need to log in before you can comment on or make changes to this bug.