record bundleID of liveslots/lockdown/supervisor with each vat

[warner]

What is the Problem Being Solved?

The kernel must be capable of reloading each living vat from state in the DB, and bringing it back to the same state it was in from the previous checkpoint. The new vat runtime is built out of several layers, all of which must be identical on each execution:

• the xsnap process (compiled from a specific version of the XS Javascript engine, plus our xsnap C code application)
• the Endo lockdown bundle we evaluate within that process, to provide SES
• the supervisor bundle we load, to define the code that processes incoming netstring commands and conveys syscalls back to the kernel process
• the liveslots code (currently incorporated into the supervisor bundle, which imports it)
• the vat bundle
• all the old deliveries into the vat
• the latest heap snapshot, which encapsulates all of the above
• the most recent deliveries into the vat (since the most recent snapshot)

Currently we bundle lockdown and supervisor during kernel initialization (exactly once, while the DB is still empty), and store the bundles into the DB using calls like kvStore.set('lockdownBundle', bundle).

This consistency is helpful, but we're looking ahead to the time when we want an established application (our chain) to start using an upgraded set of code. Existing vats must continue to run without behavior changes, so they must keep using the same lockdown/supervisor/liveslots as before, but new vats created after the upgrade point should use (or at least be able to use) new starting points.

#4376 is about the API to tell the kernel to start using a new version of liveslots (and about separating the liveslots code from the supervisor bundle, and installing it separately). But we also need to keep track of the lockdown/supervisor bundles as part of each vat's state, so some vats can use one version, while newer vats use different ones.

Description of the Design

During initializeSwingset, after we create the initial lockdown and supervisor bundles, we should compute their bundleID hashes, and store them into the bundle table (just like vat bundles and contract bundles, with an internal equivalent of controller.validateAndInstallBundle()). We should then store their bundleIDs as kvStore.set('currentLockdownBundleID')/etc.

Each time we create a new vat, we should copy the current bundle IDs into vat state, probably vatKeeper.setSourceAndOptions, stashing the IDs into the options somewhere.

Each time we launch a vat ("ensureOnline", in vat-warehouse terms), we should look up the bundle IDs, fetch the relevant bundles, and feed those bundles into the worker, rather than taking bundles that are global to the entire kernel. (This will also reduce the kernel memory footprint by about 800kB, as those bundles will live on disk most of the time).

We will then need some API to change these bundleIDs for new vats. We might not need those APIs now (i.e. wait until we have supervisor/etc changes to make). @michaelfig suggested that we could have the host application install the new bundles itself (using controller.validateAndInstallBundle(), just like with vat/contract bundles), and then the kernel API would be something like controller.updateBundleID('supervisor', newSupervisorBundleID), which could be called from the host application at a consensus-defined time.

We can imagine a vat-admin API to set this, in which case the upgrade could happen entirely within the governance layer (an external txn is used to install the new bundles, then the "big JS hammer" bootstrap governance evaluates code which tells vat-admin to tell the kernel to change the default bundle IDs. That would, of course, require the new APIs be present before we launch MN-1.

Or, the plan in #5679 (comment) might be worth considering, some way for the host application to know that it's been upgraded, but not need to know the specifics. The new source code for the lockdown/supervisor bundles would live on disk just like the new kernel source code, and what's needed is a trigger to call bundleSource again and to store the IDs.

Security Considerations

These sources affect the behavior of vats, and are the bottom layer of the worker TCB, so the ability to change the bundle IDs must be carefully controlled.

Test Plan

unit tests

[warner]

oops, dup of #5073