Isolated realms with sync messaging passing

[domenic]

Hi realms champions,

@syg and I have been considering a modification to the current realms proposal which trades some expressivity, to give better isolation guarantees. Essentially, instead of allowing direct bidirectional access between the parent realm and the constructed realm, all such communication would go through structured cloning. This ensures that the child realm never gets access to objects from the parent realm, thus making "sandbox escapes" such as those in #277 or nodejs/node#15673 impossible by construction.

Sample code and API

We don't have strong feelings on the API for this; we'd like it to be as ergonomic as possible. But here is an initial idea.

For pulling values out of the constructed realm, into the parent realm: introduce realm.eval().

const realm = new Realm();

// value is a structured clone of the completion value
const value = realm.eval("[1, { foo: 'bar' }]");

// Its prototype chain is thus based on *the parent realm*'s intrinsics
console.assert(value.__proto__ === Array.prototype);
console.assert(value[1].__proto__ === Object.prototype);

// If you try to get access to a constructed realm's prototype or constructor,
// you get a clone, which isn't very useful:

try {
  const value = realm.eval("Array");
} catch (e) {
  // Can't clone functions
}

const value2 = realm.eval("Array.prototype");
// value2 is an empty plain object (structured clone only clones enumerable properties)

For getting values into the constructed realm, from the parent realm, a bare minimum might look like this:

const realm = new Realm();

realm.set("foo", "bar");
console.assert(realm.eval("globalThis.foo === 'bar'") === true);

but you could imagine something slightly more complicated, and more useful, such as

const realm = new Realm();
realm.eval("globalThis.add = (x, y) => x + y");

const result = realm.call("add", 2, 3);
console.assert(result === 5);

(Compared to async realm boundaries on the web, this solves similar use cases to webRealm.postMessage().)

Finally, for pushing values out of the constructed realm into the parent realm, you'd need something like this:

const realm = new Realm({
  handler(...args) {
    console.assert(args[2].__proto__ == Object.prototype);
    console.log(args);
  },
  exposeHandlerAs: "callParent"
});

console.log(realm.eval("globalThis.callParent.toString()"));
// logs "function () { [native code] }": callParent is installed by the implementation inside
// the constructed realm, and structured-clones its arguments to pass to handler()
// in the outer realm.

realm.eval("globalThis.callParent(1, 2, { foo: 'bar' })");
// logs 1, 2, and (a structured clone of) the { foo: 'bar' } object

(Compared to async realm boundaries on the web, this solves similar use cases to webRealm.onmessage.)

And, of course, we'd remove realm.globalThis.

Use case analysis

This proposal is arguably better than the current one for many sandboxing use cases. In particular, for cases such as templating or computation where the goal is to have a (conceptually) pure function execute inside the realm, this architecture is ideal, especially in how it automatically prevents "impurities" from cross-realm contamination. In such cases, the values passed are often primitives, or if not, they're within the realm of structured clone: plain objects, arrays, maybe some Maps and Sets and Errors and Dates and typed arrays/ArrayBuffers.

For cases such as a virtualized environment, it requires more work, but probably on about the same level membrane-based approaches. That is, to perform operations inside the realm while interfacing with a same-realm object API, you would have to create proxies (either literal Proxys or just wrappers) which perform the appropriate calls to realm.eval() and realm.call(). And similarly for the reverse: if code inside the realm wants to operate on a inside-realm object while really doing work in the outside realm, the outside realm would need to do some setup, using realm.eval() to inject some proxies which call globalThis.callParent(). (Probably that setup code would then also do realm.eval("delete globalThis.callParent") at the end.) This is equivalent to what is being done today in the AMP WorkerDOM example that the explainer cites, but by using synchronous realm.call() etc. instead of asynchronous worker.postMessage(), it would overcome the challenges you discuss there.

Other use cases like running tests in the realm fall in between. You'd need to inject a small shim into the realm which provides globals that the test library depends on (such as console), proxied to the creator realm. But then you'd just run the test library inside the global. I.e. instead of the explainer's current sample code, you'd write

import { consoleShimOutside } from 'console-shim';
const realm = new Realm(consoleShimOutside);
realm.import('console-shim/inside');
realm.import('testFramework');
realm.import('./main-spec.js');

This also gives you a stronger guarantee that tests don't mess with the test framework, or with the outer realm, or with other tests, all of which are possible in the current explainer's sample code.

This proposal does lose some expressivity though. In particular, it is not able to create reference cycles between cross-realm objects. Because all communication is via cloned messages, there's no way to communicate to the garbage collector that an object in the outer realm depends on an object in the inner realm, and vice versa, so that the cycle can take part in liveness detection. To some extent this is a good thing, as cycles are an easy way to leak an entire realm. But from what I understand it does cut off some use cases that go beyond the ones mentioned in the current realms explainer.

Performance

Adding a structured clone step for all boundary-crossing operations could come at a performance cost. But, less so than you'd imagine.

In particular, since primitives are trivially cloneable, any operation which returns them would suffer virtually no overhead vs. the current realms proposal, when communicating across the boundaries. This can account for a large number of use cases: e.g., most computation use cases, or the test framework use case (where it's just passing console.log strings across), or many of the interesting virtualization cases. Other cases will be covered by small objects or arrays, for which the structured clone overhead is quite small (less than JSON serialization and parsing). It's only the case of needing to return a large, nested object graph where there might be a noticeable performance disadvantage.

It's also worth noting that although this proposal does have a lower theoretical performance ceiling than the current realms proposal, it's probably comparable to the current realms proposal plus the associated membrane machinery that's needed to preserve encapsulation. There might be interesting tradeoffs in the large nested object graph case. There, structured cloning across the boundary means a larger up-front cost, but after that initial cost is paid, subsequent accesses throughout the large object graph are fast and well-optimized. Whereas membrane use means every access throughout the wrapped object graph incurs membrane-related overhead.

Finally, I haven't thought much about this, but you could probably get ultimate performance™ by passing in a SharedArrayBuffer and doing all communication through that.

Conclusion

I'm optimistic that this proposal removes the most dangerous feature of realms, which is that they advertise themselves as an encapsulation mechanism, but it is extremely easy to shoot oneself in the foot and break encapsulation. This encapsulated-by-default proposal would bring realms onto the same footing as other encapsulation proposals such as trusted types or private fields, and thus make it more congruent with web platform goals.

There still remains a danger with people over-using realms when they need security or performance isolation, beyond just encapsulation. This still weighs heavily on me, and its conflict with the direction the web is going (per #238) makes me still prefer not providing a realms API at all, in order to avoid such abuse. But I recognize there are cases where synchronous access to another computation environment is valuable, and I think if we curtailed the footgun-by-default nature of realms by prohibiting direct cross-realm object access, I could make peace with the proposal.

I look forward to hearing your thoughts, and hope we can meet on this "middle ground" between no realms on the web, and the current proposal.

[Jamesernator]

My thoughts are that this is a bit weak by itself due to the lack of cross-realm references. However it does make me wonder if something like a sync version of what Puppeteer/Playwright do with JSHandles + ability to structure clone a handle would work.

e.g. For example:

const realm = new Realm();

const arrayHandle = realm.evaluateHandle(`[1,2,3]`);

// Push an item into the array in the realm, non-handles are structured cloned
realm.evaluate(`array.push(value)`, { array: arrayHandle, value: 4 });

// We can also ask for a handle to be structured cloned back to us
const arrayClone = arrayHandle.cloneIntoThisRealm();

console.log(arrayClone); // [1,2,3,4]

For things like callback patterns, the ability to have handles works naturally, for example suppose we wanted to expose something like setTimeout in the realm:

const realm = new Realm();

const realmSetTimeout = realm.createFunction(
    function setTimeout(delayHandle, callbackHandle, ...callbackArgumentHandles) {
        const delay = delayHandle.cloneIntoThisRealm();
        setTimeout(delay, () => {
            realm.evaluate(`callback(...args)`, {
                callback: callbackHandle,
                args: callbackArgumentHandles,
            });
        });
    }
);

realm.globalThisHandle.setPropertyDescriptor('setTimeout', { 
    value: realmSetTimeout,
    enumerable: true,
    configurable: true,
    writable: true,
});

---

A rough API would be something like this:

type StructuredClonable = ...;

class RealmHandle {
  // Clone the value from the realm into this Realm using structured clone
  cloneIntoThisRealm(): StructuredClonable;

  // Object meta operations, same as Reflect.* except 
  // accept RealmHandles and return RealmHandles
  apply(
    target: RealmHandle,
    thisArgument: RealmHandle | StructuredClonable,
    argumentsList: RealmHandle | Array<RealmHandle | StructuredClonable> | StructuredClonable>;
  ): RealmHandle;
  construct(...) ...
  ...
}

class Realm {
  // A RealmHandle for the global object
  get globalThisHandle(): RealmHandle;

  // Evaluate and clone the return value, this is basically a shortcut for
  // .evaluateHandle().cloneIntoThisRealm();
  evaluate(
      code: string,
      scope: Record<string, RealmHandle | StructuredClonable>,
  ): StructuredClonable;
  evaluateHandle(
      code: string,
      scope: Record<string, RealmHandle | StructuredClonable>,
  ): RealmHandle;
  // Creates a function in the Realm that calls the given function with RealmHandles
  // for all arguments passed to it
  createFunction(
      func: (...args: any[]) => StructuredClonable,
      scope: Record<string, RealmHandle | StructuredClonable>,
  ): RealmHandle;
}

[leobalter]

@domenic I want us to meet at a middle-ground for sure. I asked my teammates to take a look.

In particular, it is not able to create reference cycles between cross-realm objects. Because all communication is via cloned messages, there's no way to communicate to the garbage collector that an object in the outer realm depends on an object in the inner realm, and vice versa, so that the cycle can take part in liveness detection.

This is one of the concerns that requires specific review, I appreciate that you're weighing the options here.

[Jack-Works]

One of the problems is that we don't have structured cloning in the language. I have a proposal for that https://github.com/Jack-Works/proposal-serializer if you're interested.

[caridy]

@domenic thanks for putting the time to do this write up, we have been debating this with @syg for few weeks, in fact, we did some prototyping around it to measure perf (I believe that's not a deal breaker, which is a good news). Also, we did some homework to see if some of the existing membranes will work with this proposal, and here is where things become complicated (as @leobalter mentioned above).

One thing that occurs to me is that maybe we can provide other internal mechanism to help overcome this issue. I honestly don't even know if this is possible, but here is an idea:

realm.eval(`globalThis.foo = { x: 1 }`);
realm.eval(`Array.prototype`) === realm.eval(`Array.prototype`); // to yield `true`
realm.eval(`foo`) === realm.eval(`foo`); // to yield `true`

Basically, what I'm asking is if the UA can do some ref-tracking across this boundary, so the incubator realm's ref (in this case empty plain object based on your example) can continue to be linked to the corresponding ref from the realm, and release that memory when the realm doesn't need access to that object anymore.

This is clearly a lot different than the already well establish structured cloning algo, but a variation of it to reuse some references when possible. Since both realms are in the same process, it might be possible. Similarly, we will have to define how that works for Realm.set/call/etc. But the bottom line is that such mechanism will eliminate the necessity of doing any user-land book-keeping for references that needs to be tracked across references, clearing the way for a membrane to support any kind of virtualization.

[domenic]

I would be interested in seeing the explainer expanded to cover use cases where cross-realm cycles are important. I don't think "making existing membranes work" is a use case. I'd be interested to see things on the same level as the current explainer's "DOM virtualization" or "test frameworks". From what I can tell, no use case mentioned so far requires such cycles.

[leobalter]

I'm writing an expansion over the sandbox use case and some thoughts for perhaps have a workaround to overcome @caridy's concerns. I'll post it back here when I have a proper review.

[leobalter]

We have the TC39 plenary and a TAG Review meeting next week, they are too close for us to bring any good conclusion of potential next steps. I can say we are trying to understand better this new proposal and identify what might not work and how it would work for us. Our goal is to find an agreement point.

Meanwhile, I'm still going to expand the use cases in the explainer.

[caridy]

@domenic can you expand a little bit about whether or not the realm will be running in the same process / same agent? or if it must run in a separate process? Or is it that you have intentionally left that part out of the proposal to let the UA to decide about that? I'm asking because that might be another differentiation aspect between the two of them. Can you clarify?

[domenic]

This proposal has them running in the same process, so that the communication is synchronous. I would of course prefer them to run in separate processes, and for the communication to be asynchronous, per #238, but such a modification does break some of the use cases mentioned in the explainer. This proposal is meant to cover all of the explainer's use cases and as such is synchronous/same process.

[jridgewell]

Basically, what I'm asking is if the UA can do some ref-tracking across this boundary, so the incubator realm's ref (in this case empty plain object based on your example) can continue to be linked to the corresponding ref from the realm, and release that memory when the realm doesn't need access to that object anymore.

I'm reasonably certain we can reuse the Membrane concept even with IsolatedRealms. Whenever an object crosses the boundary, instead pass a UUID (or anything unique, really). This will require wrapping the IsolatedRealm's methods calling into the realm, and the callParent calling outside the child.

For instance, say we had an stored in the foo variable inside the realm:

realm.eval(`foo`) === realm.eval(`foo`);

Here, eval would return a Proxy, and running it twice would have to return the same Proxy instance. So, we'll store a Map<uuid, WeakRef<Proxy>>. To get around the lifetime issues, we'll need the child realm to track foo with a FinalizationRegistry, and when foo is finally reclaimed, we can just tell the parent realm to delete the uuid.

Using a Membrane, we'd additionally be able to express a cycle without any issues. If foo.bar === foo, then performing const yFoo = realm.eval('foo'); yFoo.bar === yFoo will be true, too.

[jridgewell]

To ensure the child's foo isn't reclaimed while the parent's yFoo is still alive, the child realm will need to store a Map<Object, uuid> to strongly hold onto foo. And, the parent realm will need another FinalizationRegistry to notify it when yFoo is reclaimed. If so, tell the child to remove its key for foo, and we cleanup the memory cycle.

[Jamesernator]

Using a Membrane, we'd additionally be able to express a cycle without any issues. If foo.bar === foo, then performing const yFoo = realm.eval('foo'); yFoo.bar === yFoo will be true, too.

Unfortunately cross-system cycles using UUID's can leak memory as this issue on the WeakRef proposal demonstrates. Returning an object (or symbol if they're allowed as weakmap keys) would be better as the engine itself can track cycles properly.

EDIT: Actually it's unclear with the proxy's returned by eval if this suffers the same problem as the linked thread, this would need some investigation.

[erights]

WeakMaps enable cross-membrane cycles to be collected. WeakRefs do not. That was one of the first motivations for splitting the concepts.

[ByteEater-pl]

Why not both? It looks like with the proposal accepted the kind of realms proposed in this issue could be implemented in userland. So maybe just do it and make programmers widely aware of its advantages. If deemed desirable, they could be included in the language as well as the full version, e.g. as a subclass.