Reify syscall.vatstoreXXX API as a vatPower

[FUDCo]

What is the Problem Being Solved?

LiveSlots has access to the vatstore syscalls (as part of the regular syscall interface), which it uses to realize virtual objects and their relatives. LiveSlots does not make this power available to vats directly since it is too low-level and would enable various shenanigans. On the other hand, vats which are created using setup instead of liveSlots do have access to the vatstore since they are given the syscall object directly; the presumption is that such vats (e.g., the comms vat) are special vats trusted to behave responsibly with the authority they are given.

However, there are use cases that could benefit from direct access to persistent storage but which currently cannot because they are implemented using liveSlots rather than setup, mostly to avoid having to manually reimplement all the support machinery that liveSlots provides. The notable example of this category that we have in mind is the vattp vat, which is almost but not quite stateless. It could, with access to a small bit of persistent storage, do without a transcript and thus realize substantial savings on both replay time and transcript storage space (which is a lot because all network traffic flows through it).

Description of the Design

The design consists of two pieces:

• a reified vatstore object implemented inside liveSlots that could be selectively provided to vats as a vatPower
• a vat configuration parameter that controls whether this power should be granted to the vat or not (much as we now control metering or transcriptlessness).

The vatstore object would be provided as vatPowers.vatstore, with an API of the form

{
  get: (key: string) => string,
  set: (key: string, value: string) => void,
  delete: (key: string) => void,
}

which is essentially the same API as provided by the vatstore subset of the syscall interface, and would be realized by more-or-less direct translation into the corresponding syscalls, though with a prefix string applied to keys to ensure that things accessed via this API are not comingled with liveSlot's other uses of the vatstore.

For the configuration parameter I propose enableVatstore, a boolean (default false), which should follow essentially the same control logic as useTranscript.

Security Considerations

The vatstore implementation already assigns each vat a separate subset of the storage key space so that the vats' respective uses of the store are isolated from each other. As discussed above, the mechanism that exposes the store to the vat directly will need to further subset the key space in order to ensure that uses by the vat are isolated from other uses by liveSlots (e.g., virtual objects).

Test Plan

It should be straightforward to derive tests from essentially the same tests we already use for the vatstore itself, except modified to access the store from within a vat using the vatstore power.

[warner]

a vat configuration parameter that controls whether this power should be granted to the vat or not (much as we now control metering or transcriptlessness).

It's not a big deal, but I don't think we need this control. The "shenanigans" referred to earlier are collisions between the keyspace available to user-level vat code (vatPowers.vatstore.set('foo', value)) and the keyspace used by more-powerful lower-level liveslots code (e.g. the virtual object manager). These two keyspaces must not overlap. It would be an integrity error to allow userspace vatstore.set() to modify the VOM's entries: such code could forge references to any vref it wanted, or modify the virtualized data in objects that it would not otherwise have access to.

As long as we have distinct keyspaces (enforced by applying a different prefix to each "user": the VOM gets one, userspace gets a different one), then there's no concern about integrity or safety.

Now, userspace access to vatstore does represent a storage authority, but 1: we'd rather vats store things on disk than in RAM, at least numerous or large things, and 2: userspace can already consume disk storage via virtual objects. So I don't see a big need to restrict it to certain vats.

That said, if it's already implemented that way, I'm ok with being conservative about sharing features with userspace until we have a good sense about how they'll be used. I suspect the "virtual collections" work (#2004) might be the first non-vattp user of this feature, if implemented in userspace.

[FUDCo]

Closed by #3304