Use thenables for promises as delivery arguments #8469
Labels
enhancement
New feature or request
liveslots
requires vat-upgrade to deploy changes
SwingSet
package: SwingSet
What is the Problem Being Solved?
In #6074 we identified a sort of memory growth that can be imposed onto a vat: a promise sent as payload to a delivery (arguments to a send, or nested in a resolution value). Liveslots will automatically subscribe to these promises because it cannot sense when/if the userland ever use these promises.
While #6075 would solve this problem by unsubscribing when liveslots detects the promise is no longer needed, that approach relies on GC, leaving a transient subscribe of the promise that may not be needed in the first place.
Description of the Design
Liveslots could create a "thenable" instead of a native promise for any promise imported and used as payload to a delivery. It could then avoid auto-subscribing, and only subscribe on the first
then
invocation. This would requirepassStyleOf
to be changed to allow thenables (currently enforces native promises, and we were considering disallowing thenable as pseudo-promises).We likely would still need a GC based mechanism to drop the imported but not subscribed promise from the clist (making promises more like regular imports)
It is also technically possible for a promise to first show as payload in a delivery and then be used as the result of a delivery, with the vat becoming the decider. Liveslots needs to not become confused in this case.
Security Considerations
Solve a resource exhaustion vector.
Must correctly handle cases where decider changes.
Must not allow sensing of GC through unsubscribed promises, e.g. by always creating a new thenable when unmarshalling a delivery payload.
Scaling Considerations
None
Test Plan
TBD
Upgrade Considerations
This requires a liveslots upgrade, and likely a corresponding kernel upgrade since the gc mechanism and auto-subscribe logic would change. As such, the kernel side would likely need to support both liveslots behavior, unless we could force upgrade all vats.
The text was updated successfully, but these errors were encountered: