mark all core vats as "critical"

[warner]

What is the Problem Being Solved?

Our initial chain will consist of about 20 vats: bootstrap, a handful of static vats (some created by the kernel itself), a bunch of dynamic vats created by bootstrap, and then a bunch of contract vats created by zoe (either during bootstap or during an "enable the economy" governance event shortly afterwards).

At this stage, if any of these vats fail, we should panic the kernel and halt the chain. It would be better to stop the chain than to move forward without any of these vats.

Description of the Design

For static vats, we have a flag for this: you just set config.vats.NAME.creationOptions.critical = true. So the task is to modify packages/vats/*-config.json to add this flag to the static vats defined therein.

For dynamic vats, the party doing the creation (either bootstrap or zoe) must provide a special criticalVatKey object in an option to the createVat call. This object can only be obtained from the vat-admin root object (which is distinct from the vatAdminService on which one calls createVat):

// bootstrap method in vat-bootstrap
function bootstrap(vats, devices) {
  const critical = await E(vats.vatAdmin).getCriticalVatKey();
  // then, later:
  E(vatAdminService).createVat(bundlecap, { critical }).then(..);
}

So the tasks are:

• 1: bootstrap should fetch getCriticalVatKey() from the vat-admin root object and produce it to a slot named criticalVatKey
• 2: bootstrap's makeVat code should consume that slot and use it as the critical: option in its createVat() calls, so all the initial dynamic vats (like zoe) will be marked as critical
• 3: I think bootstrap is the one that builds a createZcfVat for Zoe, so bootstrap needs to imbue that function with criticalVatKey, so all contract vats that Zoe creates will be marked as critical

After our initial launch, zoe should certainly not be marking all contract vats as critical. For one, that would allow any third-party contract to halt the chain. But also we expect to be creating more contract instances as the chain matures, and many of them will be short-lived or will serve a smaller audience, where their termination is expected and will be more tolerated.

Security Considerations

Without this change, certain unexpected failure modes (vats consume more than 2 GiB of RAM, emit oversized netstring messages, or suffer some internal consistency error that manifests as an illegal syscall) will terminate the vat and then commit (within consensus) the deletion of the vat's state. This will make recovery more difficult, as we'll have to roll back the state by a block or two, instead of distributing new software that only has to fix the terminating behavior.

Test Plan

It'd be nice to somehow trigger a vat failure and make sure the chain halts, but it might be good enough to just inspect the config files and slogfiles once (looking for the isCritical option in the vatOptions).