Open warner opened 3 years ago
I'd also like us to look critically at the inescapableGlobalProperties
which were added to prevent userspace code from reaching the real WeakMap
and WeakSet
. In particular I want a unit test that demonstrates a child Compartment cannot be used to escape the modifications, even if it sets the inescapableGlobalProperties
option to something unusual, or if they delete globalThis.WeakMap
or something.
And, I want a review of our replacement WeakMap
/WeakSet
implementations, to make sure e.g. code which subclasses them cannot interfere with their behavior.
What is the Problem Being Solved?
@FUDCo and I have talked about a lot of potential non-determinism in the virtual object manager, and we've thought of and/or implemented many defenses, but I'm still nervous. We need to do a careful examination of the API and implementation, to see if there's any way adversarial code can use it to learn about GC events that they're not supposed to have access to.
The requirements are:
state
of a Representative, or looks up something in a virtualized collection), it will always provide an existing Representative if one exists, to maintain the property that userspace only ever sees a single Representative (or Presence) per vref at a timevatstore
syscalls must not depend upon which case occurredI want to investigate sneaky things like:
self
capturing some per-kind-constructor-invocation value that is different each timestate
object against some previous valueinit()
-timestate
object is special: it is a normal mutable object, so we can sense what properties are added to itinit()
always sees a distinct object from all other calls (which merely reanimate the object, as opposed to allocating a new vref)state
object (most likely), or always see distinct ones (less likely)self
value created by the constructor against other RepresentativesProxy
instate
and measuring how many times it is accessedSecurity Considerations
If adversarial userspace code can use virtual object behavior to sense when GC has happened, it can behave differently on some validators than others, causing grief or (worst case) a complete chain halt (if they manage a 50/50 split). If they could target a specific validator, they could get that validator kicked out of the voting set, possibly increasing their own voting power in the process.
Test Plan
I'd like to see a few unit tests that exercise any problems we think up (where the test exercises both a "force GC in the middle" case and a "don't force GC" case). But in general I suspect this is a "read the code and think very carefully about it" task, more than a "write new code" task.