Re: [v8-users] Appropriate use of Context and Isolate

[Chris Dumoulin]

Ben, thanks a lot for your answers. This is helpful information.

On Wednesday, 21 February 2018 15:44:31 UTC-5, Ben Noordhuis wrote:
>
> On Wed, Feb 21, 2018 at 9:05 PM, Chris Dumoulin  > wrote: 
> > In the Embedder's Guide, Contexts are described as allowing "separate, 
> > unrelated, JavaScript applications to run in a single instance of V8". 
> > Also, the section on Security Model says that "In V8 an 'origin' is 
> defined 
> > as a context." However, I'm pretty sure that Chrome uses separate 
> Isolates 
> > within separate processes to isolate different browser tabs. 
>
> Tabs use different isolates. 
>
> Iframes in the same tab use different contexts but the same isolate. 
>
> Workers in the same tab use different isolates.  I don't know if 
> Chromium puts them in separate processes but I expect it does. 
>
> > My questions are about running untrusted Javascript code, and the 
> > appropriate use of Isolates and Contexts, with respect to security and 
> > isolation of separate, unrelated, Javascript. 
> > - What safeties are in place that prevent Javascript from breaking out 
> of a 
> > Context? 
>
> Context::SetSecurityToken() - contexts with different tokens can't 
> access each other's objects; that includes arrays and functions. 
>
> > - What safeties are in place that prevent Javascript from breaking out 
> of an 
> > Isolate? 
>
> The observation that the V8 team would panic if that was possible. :-) 
>
> It would be a pretty serious security vulnerability and Google takes 
> those seriously. Report one or two good ones through the bug bounty 
> program and you could take the rest of the year off. 
>
> > - From a security perspective, is there a benefit to using separate 
> Isolates 
> > within a single OS process, or would separate Contexts be just as good? 
> I'm 
> > aware that Isolates don't support concurrent, multithreaded access. 
>
> They are functionally equivalent.  The moat might be marginally deeper 
> in case of security breach with isolates.  If you had to pick one or 
> the other, pick isolates (and process isolation.) 
>
> > I expect that sandboxing separate OS processes for unrelated, untrusted 
> > Javascript files/applications is the most secure solution, but I'm 
> trying to 
> > figure out how much better that is than multiple Contexts or Isolates 
> within 
> > a single process. 
>
> The single process approach doesn't protect against out-of-memory 
> conditions in a context or isolate.  V8 doesn't handle OOMs except by 
> terminating.  It's not difficult for JS code to trigger an OOM: `for 
> (let a = [];;) a.push(a)` will do it. 
>
> Infinite loops are another issue a single process won't protect you 
> against, at least not without coding your own watchdog functionality 
> from scratch. 
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Appropriate use of Context and Isolate

[Ben Noordhuis]

On Wed, Feb 21, 2018 at 9:05 PM, Chris Dumoulin  wrote:
> In the Embedder's Guide, Contexts are described as allowing "separate,
> unrelated, JavaScript applications to run in a single instance of V8".
> Also, the section on Security Model says that "In V8 an 'origin' is defined
> as a context." However, I'm pretty sure that Chrome uses separate Isolates
> within separate processes to isolate different browser tabs.

Tabs use different isolates.

Iframes in the same tab use different contexts but the same isolate.

Workers in the same tab use different isolates.  I don't know if
Chromium puts them in separate processes but I expect it does.

> My questions are about running untrusted Javascript code, and the
> appropriate use of Isolates and Contexts, with respect to security and
> isolation of separate, unrelated, Javascript.
> - What safeties are in place that prevent Javascript from breaking out of a
> Context?

Context::SetSecurityToken() - contexts with different tokens can't
access each other's objects; that includes arrays and functions.

> - What safeties are in place that prevent Javascript from breaking out of an
> Isolate?

The observation that the V8 team would panic if that was possible. :-)

It would be a pretty serious security vulnerability and Google takes
those seriously. Report one or two good ones through the bug bounty
program and you could take the rest of the year off.

> - From a security perspective, is there a benefit to using separate Isolates
> within a single OS process, or would separate Contexts be just as good? I'm
> aware that Isolates don't support concurrent, multithreaded access.

They are functionally equivalent.  The moat might be marginally deeper
in case of security breach with isolates.  If you had to pick one or
the other, pick isolates (and process isolation.)

> I expect that sandboxing separate OS processes for unrelated, untrusted
> Javascript files/applications is the most secure solution, but I'm trying to
> figure out how much better that is than multiple Contexts or Isolates within
> a single process.

The single process approach doesn't protect against out-of-memory
conditions in a context or isolate.  V8 doesn't handle OOMs except by
terminating.  It's not difficult for JS code to trigger an OOM: `for
(let a = [];;) a.push(a)` will do it.

Infinite loops are another issue a single process won't protect you
against, at least not without coding your own watchdog functionality
from scratch.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Appropriate use of Context and Isolate

[Chris Dumoulin]

In the Embedder's Guide 
, Contexts are 
described as allowing "separate, unrelated, JavaScript applications to run 
in a single instance of V8".  Also, the section on Security Model 
 says that 
"In V8 an 'origin' is defined as a context." However, I'm pretty sure that 
Chrome uses separate Isolates within separate processes to isolate 
different browser tabs.

My questions are about running untrusted Javascript code, and the 
appropriate use of Isolates and Contexts, with respect to security and 
isolation of separate, unrelated, Javascript.
- What safeties are in place that prevent Javascript from breaking out of a 
Context?
- What safeties are in place that prevent Javascript from breaking out of 
an Isolate?
- From a security perspective, is there a benefit to using separate 
Isolates within a single OS process, or would separate Contexts be just as 
good? I'm aware that Isolates don't support concurrent, multithreaded 
access.

I expect that sandboxing separate OS processes for unrelated, untrusted 
Javascript files/applications is the most secure solution, but I'm trying 
to figure out how much better that is than multiple Contexts or Isolates 
within a single process.

Thanks,
Chris

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Cached data or startup snapshot?

[Yang Guo]

Some comments:

- When you say classes run slower, do you mean they take longer to execute, 
or do you mean they spend time on compilation too?
- Does your non-snapshotted version use proxies too? Proxies are indeed 
significantly slower.
- You should no longer need --ignition --turbo. This is the default with 
the newest V8.
- What version of V8 are you using?
- It's not expected that code in the snapshot is slower than code at 
runtime. But I expect that there is no code embedded in the snapshot in the 
first place.
- Do you have a small repro I can play with? E.g. source to include in the 
snapshot and the code to run. Ideally pure JS that I can run in Node.

Cheers,

Yang

On Friday, February 16, 2018 at 3:33:11 PM UTC+1, Alexandru Dima wrote:
>
> Hi Yang,
>
> Thanks for answering!
>
> I only snapshot pure JS code (written in AMD form), and when the JS code 
> needs node modules (built-in, native, JS only, etc), I feed it proxy 
> objects (`new Proxy`). Here is how the code I snapshot looks like - 
> https://gist.github.com/alexandrudima/bda598fbed179a581986b634cc94ab8d
>
> I am trying to implement what is described here[1] for VS Code (also an 
> Electron app). Perhaps the main difference is that I can snapshot a huge 
> amount of code, as we compile our code to AMD and I don't need to hack or 
> do anything with node's require to stitch things up. I also wrote our own 
> AMD loader, so I can do everything I need to in order to snapshot basically 
> all of our code. I am running `mksnapshot start.js 
> --startup_blob snapshot_blob.bin`. This creates a 40 MB `snapshot_blob.bin` 
> file, which I use to overwrite the original 1.3 MB `snapshot_blob.bin` file 
> that ships with Electron. The 40MB snapshot is effectively the entire VS 
> Code application (except for node modules, for which the code has 
> references to proxy objects).
>
> The file I am producing, snapshot_blob.bin, contains all the heap state 
> after executing the code in start.js. The heap state includes all the AMD 
> modules, with their exports, such as class definitions (functions with 
> prototypes), all the other utility functions, statics, etc, which I can 
> call and execute directly without loading any additional JS source code in 
> the VM at runtime. Sorry for calling it "snapshotted code", but that's what 
> I meant. My code is there, available, I don't need to load it, so it is a 
> part of the snapshot...
>
> At runtime, when the application starts up, there is startup code (part of 
> the snapshot too) which will begin to instantiate those classes (also part 
> of the snapshot), will then proceed to look at what folder/files you have 
> opened, what is the environment, what folder you have opened, etc. and 
> eventually will "paint" by creating DOM nodes, etc...
>
> My problem is that these classes, which are captured in the snapshot, are 
> significantly slower when I execute them, compared to when those same 
> classes (same code) are loaded from source or from code caching. I was 
> trying to capture this problem in my original screenshots. The "shell open" 
> part of the two screenshots shows this problem. When loading code from 
> source or from code caching, the JS profiler shows that everything is 
> "squashed" into the `runCallback` method. When running the classes as they 
> are captured in the snapshot, the JS profiler shows perhaps each and every 
> function call.
>
> I have followed some of your tips from here [2], i.e. I tried running 
> `mksnapshot --ignition --turbo start.js --startup_blob snapshot_blob.bin`
>
> I also tried running `mksnapshot --no-lazy start.js --startup_blob 
> snapshot_blob.bin`.
>
> All of these tweaks resulted in varying sizes in the output 
> `snapshot_blob.bin`, but the speed of the executing code was still slower.
>
> I am wondering if I am doing something silly (e.g. perhaps by using 
> proxies, or if the v8 flags don't 100% match at runtime, should --ignition 
> --turbo be there at runtime too ?) or is it expected that functions (code) 
> included in a snapshot are slower than those loaded at runtime?
>
> Thank you again for your time,
> Alex
>
> [1] 
> https://blog.atom.io/2017/04/18/improving-startup-time.html#v8-snapshots 
> [2] https://github.com/nwjs/nw.js/issues/269#issuecomment-224490557
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.