-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ShadowRealm Integration #42528
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
What sort of guarantees do we get in terms of isolation? Do we have a proven (as in formally) sandbox that is unescapable except with side-channels? This enables some interesting use cases and I'm wondering if this means we can relax our "Do not use this for security" bits on vm (and build it on top of this) |
The isolation guarantee of the ShadowRealm is about the isolation of the object graphs. This indicates that we will not accidentally exposes JavaScript vulnerable built-ins to the ShadowRealm, like what let ctx = vm.createContext();
let fn = vm.runInContext('...', ctx);
fn({}) // <= the function created in the vm can get access to the OUTER `Object` and hijack its methods However, since the code evaluated in the ShadowRealm is still sharing the heap with the code outside of the ShadowRealm. This means it is still vulnerable to Spectre, etc. For Host APIs exposed in the ShadowRealm, technically, we are expecting them to be side-effects free -- and thus can not be utilized to initiate attacks on the host environment. (@benjamingr I assume you closed the issue accidentally? I'm reopening this) |
Yes, sorry. |
Yeah I think side-channels in general are outside of scope of things like ShadowRealm - even if we run it in a worker (or in a container in a worker that's still not enough to mitigate side channel attacks). IIRC @erights pointed out there is a way to avoid side-channels: we can choose not to expose APIs (like process.hrtime) that allow time measurement (this also includes stuff like Date.now(), performance.now(), some parts of http and a bunch of others). |
The SES proposal is designed to deal with all that sort've stuff, Note that the web is already planning on exposing all sorts of things like high resolution timers into |
Add initial shadow realm support behind an off-by-default flag `--experimental-shadow-realm`. PR-URL: #42869 Refs: #42528 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Darshan Sen <[email protected]>
Is this the best issue to discuss what APIs should and shouldn't be exposed in ShadowRealms, or what impact ShadowRealm execution should have on the incubator realm? In general user code in one realm should avoid being exposed to objects from another realm, when either or both are a ShadowRealm. The obvious case is incubator realm objects leaking into a ShadowRealm, but that also implies shielding user code in the incubator realm from ShadowRealm objects, and being extremely diligent in node internals that may handle a ShadowRealm object (it'd be best avoided if possible). One thing that comes to mind are all the "global hooks" that node provides. For example, |
@mhofman thank you for your ideas! I think this is a very crucial part of the feature too.
Events like Or we can route them to an eventemitter that acts as the For |
Add initial shadow realm support behind an off-by-default flag `--experimental-shadow-realm`. PR-URL: #42869 Refs: #42528 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Darshan Sen <[email protected]>
PR-URL: #44056 Refs: #42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
PR-URL: nodejs#44056 Refs: nodejs#42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
PR-URL: nodejs#44056 Refs: nodejs#42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
PR-URL: #44056 Backport-PR-URL: #44251 Refs: #42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
To distinguish per-context values from the node::Environment, split those values to a new node::Realm structure and consolidate bootstrapping methods with it. PR-URL: #44179 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
Each Realm tracks its own cleanup hooks and drains the hooks when it is going to be destroyed. Moves the implementations of the cleanup queue to its own class so that it can be used in `node::Realm` too. PR-URL: #44379 Refs: #44348 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]>
PR-URL: nodejs#44056 Refs: nodejs#42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
To distinguish per-context values from the node::Environment, split those values to a new node::Realm structure and consolidate bootstrapping methods with it. PR-URL: nodejs#44179 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Create worker binding templates in the per-isolate initialization. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: nodejs#45547 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Create worker binding templates in the per-isolate initialization. PR-URL: nodejs#45547 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Create worker binding templates in the per-isolate initialization. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs/node#44056 Backport-PR-URL: nodejs/node#44542 Refs: nodejs/node#42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
PR-URL: nodejs/node#44056 Backport-PR-URL: nodejs/node#44542 Refs: nodejs/node#42528 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Feng Yu <[email protected]>
To distinguish per-context values from the node::Environment, split those values to a new node::Realm structure and consolidate bootstrapping methods with it. PR-URL: #44179 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
BaseObject is a wrapper around JS objects. These objects should be created in a node::Realm and destroyed when their associated realm is cleaning up. PR-URL: #44348 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Create worker binding templates in the per-isolate initialization. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Create worker binding templates in the per-isolate initialization. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
To distinguish per-context values from the node::Environment, split those values to a new node::Realm structure and consolidate bootstrapping methods with it. PR-URL: nodejs#44179 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
To distinguish per-context values from the node::Environment, split those values to a new node::Realm structure and consolidate bootstrapping methods with it. PR-URL: nodejs#44179 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined with extended attributes `[Exposed=*]`. The ShadowRealm instances are garbage-collected once it is unreachable. However, V8 can not infer the reference cycles between the per-realm strong persistent function handles and the realm's context handle. To allow the context to be gc-ed once it is not reachable, the per-realm persistent handles are attached to the context's global object and the persistent handles are set as weak. PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined with extended attributes `[Exposed=*]`. The ShadowRealm instances are garbage-collected once it is unreachable. However, V8 can not infer the reference cycles between the per-realm strong persistent function handles and the realm's context handle. To allow the context to be gc-ed once it is not reachable, the per-realm persistent handles are attached to the context's global object and the persistent handles are set as weak. PR-URL: #46809 Refs: #42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
PR-URL: nodejs#46809 Refs: nodejs#42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
This is the initial work to bootstrap Web interfaces that are defined with extended attributes `[Exposed=*]`. The ShadowRealm instances are garbage-collected once it is unreachable. However, V8 can not infer the reference cycles between the per-realm strong persistent function handles and the realm's context handle. To allow the context to be gc-ed once it is not reachable, the per-realm persistent handles are attached to the context's global object and the persistent handles are set as weak. PR-URL: nodejs#46809 Refs: nodejs#42528 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Joyee Cheung <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: nodejs#45547 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Create worker binding templates in the per-isolate initialization. PR-URL: nodejs#45547 Refs: nodejs#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: #45547 Refs: #42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: nodejs/node#45547 Refs: nodejs/node#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
Bindings that need to be loaded in distinct contexts of node::Realm in the same node::Environment instance needs to share the per-isolate templates. Add a new binding registration callback, which is called with per-IsolateData. This allows bindings to define templates and share them across realms eagerly, and avoid accidental modification on the templates when the per-context callback is called multiple times. This also tracks loaded bindings and built-in modules with node::Realm. PR-URL: nodejs/node#45547 Refs: nodejs/node#42528 Reviewed-By: Joyee Cheung <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]>
What is the problem this feature will solve?
ShadowRealm is a TC39 stage 3 proposal that introduces a new built-in to provide a distinct global environment, with its own global object containing its own intrinsics and built-ins. Its ability is similar to Node.js built-in
vm.Context
, however, ShadowRealm provides a stronger guarantee on object exchanges across realm boundaries.As the ShadowRealm is a distinct global environment, Web integration is also under work (Like 1) to define which web APIs should be exposed in the ShadowRealm so that people can still utilize the Web APIs that still useful in the ShadowRealm. The line generally draw between the APIs that should be exposed in the ShadowRealm or not is generally if the APIs are side-effect-free to the host environment.
What is the feature you are proposing to solve the problem?
ShadowRealm is currently under active development in v8. The design doc of the Host API could be found at here. I'd believe in Node.js we may need to be able to re-evaluate the native modules in the ShadowRealm so that their object graph is not tangled with the main context, to not violate the principle of the design. /cc @nodejs/startup
I'd believe there are a bunch of modules that are useful and can stand in the line of side-effect-free, like EventEmitter, Stream, URL, etc. Also, the Web APIs that are available in Node.js like WebStream could also follow the Web specs to be exposed in the ShadowRealm. We may need to list all the possibilities that can be available in the ShadowRealm, and eventually make them available in the ShadowRealm.
Design Doc: https://docs.google.com/document/d/12_CkX6KbM9kt_lj1pdEgLB8-HQaozkJb7_nwQnHfTTg/edit?usp=sharing
/cc @nodejs/vm
The text was updated successfully, but these errors were encountered: