Unhandled rejection can expose GC to user code

[mhofman]

Describe the bug

The unhandled rejection logic in xsnap-worker is to invoke console.error in the start compartment (supervisor), when the unhandled promise is GCed. Because of the workaround for #6784, and the fact XS internally keeps these unhandled promises in a WeakRef, these are only collected during BOYD.

So far, so good, all is deterministic, but unfortunately console.error uses object-inpect.js to issue a command to log the unhandled rejection, which may invoke user code if the reason value of the rejection can trap (e.g. using accessors or a proxy), which means the user code is now capable of sensing gc. It also means user code is potentially executing during the BOYD delivery.

Expected behavior

User code is not able to sense gc through unhandled rejections

[mhofman]

One solution may be to harden object-inspect.js to not trigger any user code. That would require jumping through hoops to only traverse non-proxy objects and only data properties.

[gibson042]

I think that would require many changes to object-inspect.js and/or replacing the native Proxy in workers, but it does feel like the right approach.

[mhofman]

Yes, we are already planning on replacing the Proxy constructor available to vat code with a stamping one, and gain an IsProxy predicate (the original motivations is passStyleOf checks). See #3905