slots in vatAdmin terminate/createVat are not translated correctly

[warner]

While working on #4566 I realized that we're probably mishandling object references (slots) in the "terminate vat from the outside" case:

// this is vat 1
  const { admin } = await E(vatAdminService).createVat(bundlecap);
  const obj = Far('iface', {});
  const reason = [ 'data', obj ]; // usually an Error, but anything is legal
  E(admin).terminateWithFailure(reason);

The object obj is assigned a vat-1 vref as terminateWithFailure gets serialized for syscall.send, then assigned a kref as the syscall is translated. When the message is delivered to vat-admin, the c-list allocates a vat-admin vref, which is what appears at the vatAdminWrapper.js terminateWithFailure() call:

    const adminNode = Far('adminNode', {
      terminateWithFailure(reason) {
        D(vatAdminNode).terminateWithFailure(vatID, reason);
      },

The D(vatAdminNode) does a syscall.callNow, which translates the vref through the kref into a devices.vatAdmin dref, which is what arrives at the device code.

Previously (on current trunk), the device code was written with deviceSlots, which provided a copy of its m.serialize to the device code, so vatAdmin-src.js could re-serialize the reason object into capdata. vatAdmin-src.js then passed the reason capdata to its kernel endowment (terminate(vatID, serialize(reason))).

The problem is that serialize(reason) is device-side capdata, with "drefs" (the device equivalent of "vrefs" in a vat). But the kernel terminate endowment is going to use that reason capdata to reject the admin.done() promise: the kernel enqueues a vatTerminated message to vat-admin, and queueToKref assumes that the arguments you give it use krefs.

The consequence is that when we attempt to deliver the vatTerminated to vat-admin, the translator will encounter invalid slot types. This will either cause a kernel panic, or cause the failure of that message (and admin.done() will never fire), probably the former.

In my #4566 rewrite, I encountered the same problem in a raw-device form of vatAdmin-src.js. I get dref capdata from the dispatch.invoke, and I want to provide kref capdata to the kernel endowment.

The same problem exists in createVat with the options argument. This one is more pressing because #4381 will want to include bundlecaps in options.vatParameters.

For now, I'm adding an assertion that the .slots are empty, so we catch this in the calling vat. For most of these methods that's going to be vatAdminWrapper.js, which will probably cause the terminateWithFailure() or createVat() to fail, which is a perfectly reasonable way to handle it. But to implement #4381 we'll need something better.

It probably wants to be a syscall, because that provides an easy place to perform dref-to-kref translation. But after translation, we want to hit some kernel-provided API. The terminate case has no return value, but the createVat cases want to return a vatID from that API.

This might overlap with #720 (a kernel input queue). One thought is that the built-in device might be given an endowment which is a marker/handle object (one for terminate, another one or two for createVat/createVatByBundle). We add a syscall.triggerKernelSomething(handle, deviceCapdata), the syscall translates deviceCapdata into kernelCapdata, then invokes whatever function the kernel had previously registered with handle (possibly through a queue that protects the kernel from reentrancy).

The way this interacts with #720 would be that external callers could invoke the device's exterior APIs any time they want, and syscall.triggerKernelSomething would know to queue the actual translation and invocation until the kernel was safely idle. I'm not sure that's sound.

[Tartuffo]

Chip's latest may make only one vat crash.