audit virtual object manager for non-determinism against adversarial code #3116
Labels
enhancement
New feature or request
liveslots
requires vat-upgrade to deploy changes
security
SwingSet
package: SwingSet
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.
The text was updated successfully, but these errors were encountered: