6 ms·

V8 release v6.9

103 points by stablemap 8y ago

giancarlostoro 8y ago
Interested in those WebAssembly updates, hopefully someday Electron will see more WebAssembly usage (maybe mostly for games?) which should be interesting. I wonder if Kotlin will ever focus on running on WebAssembly.
- Avamander 8y ago
  I'm interested in seeing a whole new world of wasm exploits. I have a strong suspicion we're going to see the same types of bugs we're seeing with C and C++ in browsers which sounds a bit scary to be honest.
  - deweller 8y ago
    I'm sure there will be exploits, as the attack surface will become bigger. But isn't wasm designed from the ground up to be sandboxed in a certain memory space? And won't that prevent buffer overruns from gaining access to other parts of the browser?
    - pjmlp 8y ago
      Yes it is sanboxed, but the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled.
      - magicalist 8y ago
        > the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled. it can be, but there are large classes of security issues that aren't possible like they usually are with those languages. eg it's not possible to jump to arbitrary locations, you can't write to executable memory, etc. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
        pjmlp 8y ago
        Still not having bounds protection is a very big one, and 40 years of CVE history doesn't help.
        vardump 8y ago
        WebAssembly does have bounds checking, you can't write outside the designated memory block. On 64-bit systems with virtual address space to spare, you can offload bounds checking to MMU by memory mapping 2 GB+ protection zone both below and above the exposed memory region. If you then limit all pointers/offsets to 32-bit, there should be no direct way to corrupt anything else. You can't reach anything interesting within 32-bit offsets. Of course one can corrupt WebAssembly instance memory all they want, but it won't matter. Performance and security win. Left CPU bugs outside consideration, hopefully those can be addressed in WASM codegen. Not like it's that different from current Javascript JIT cases.
        pjmlp 8y ago
        The memory block contains all data together in well, a block, thus you can happily overwrite two neighbouring arrays, unless I am missing something here WebAssembly does not have fat pointers.
        vardump 8y ago
        Sure, you can corrupt all the data in your instance. You can't overwrite code or the true call stack, so what's the (security) risk?
        pjmlp 8y ago
        Funny question, basically with corrupted data anything goes. For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor. But yeah, code and true call stack will be perfectly safe.
  - stcredzero 8y ago
    It's also true that some huge fraction of Dalvik/Android exploits were based on the same sorts of optimizations which can be used to make wasm faster.
  - rightbyte 8y ago
    I got this feeling that the main selling point of wasm will be "certified" software with some middle man and control. An analogy would be Google's push for https, for our own best ofc.
    - AgentME 8y ago
      WebAssembly works pretty much like Javascript: it doesn't have any new platform APIs, browsers can execute it without special permissions, it can be retrieved from a web server, etc. Any planned lockdown of it would be just as easy to do with javascript.
shawn 8y ago
Built-in functions currently consume 700 KB in each Isolate (an Isolate roughly corresponds to a browser tab in Chrome). This is quite wasteful, and last year we began working on reducing this overhead. In V8 v6.4, we shipped lazy deserialization, ensuring that each Isolate only pays for the built-ins that it actually needs (but each Isolate still had its own copy). Also known as Autoload. What’s old is new again... http://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html http://www.gnu.org/software/emacs/manual/html_node/elisp/Aut... Embedded built-ins go one step further. An embedded built-in is shared by all Isolates, and embedded into the binary itself instead of copied onto the JavaScript heap. This means that built-ins exist in memory only once regardless of how many Isolates are running, an especially useful property now that Site Isolation has been enabled by default. Inb4 security vuln in a builtin is used to pivot across tabs or reveal state in other tabs. Like, say, a timing attack on regex exec to reveal whether the word “Facebook” appears in some other tab. </baseless>
- vorpalhex 8y ago
  Since you're obviously a savant, it's curious that you don't simply contribute to v8 development given that it's open source.
  - shawn 8y ago
    They’ll have to wait in line. My time is far too valuable to give it away. I have tremendous things to accomplish. Actually, I would be surprised if a vuln creeps its way into a builtin. Most of the runtime should be stateless, and regex exec was the only one I could think of that might do some fancy memoization. But I hear it’s fun to collect a paycheck at pwn2own.
  - slimsag 8y ago
    I love WebAssembly and I don't agree with GP at all here, but this prevailing holier-than-thou attitude of "You shouldn't complain or poke holes in things unless you're willing to fix them yourself" is just silly, so I down-voted you. Trying to poke holes in things, or raising concerns about them, is contributing. I would rather hear other people's arguments (even if I don't agree with them) than silence them on the grounds of "let's see you do better n00b".
bovermyer 8y ago
This is the bit I'm most interested in: > WebAssembly got a new baseline compiler for much faster startup of complex websites with big WebAssembly modules (such as Google Earth and AutoCAD). Depending on the hardware we are seeing speedups of more than 10×. Stay tuned for more details in a separate blog post.
- chacham15 8y ago
  I'll be excited about WebAssembly when it can manipulate DOM. Until then, it feels mostly like a thought experiment in that the number of people that it makes sense to use right now is miniscule.
  - chinedufn 8y ago
    Check out Rust’s wasm-bindgen - https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen if ya haven’t already. Right now it you call into JS to interact with the DOM but when the host bindings proposal sees fruit it’ll replace the JS shims with direct DOM manipulation!
    - seanmcdirmid 8y ago
      It isn’t clear how they will allow safe access to the DOM without GC. Maybe they’ll take an approach like Microsoft did with UWP and use reference counting?
      - tjallingt 8y ago
        Would be interesting if it would be possible to take the Rust approach and guarantee at parse/compilation time that the DOM interactions are safe without runtime overhead. Probably a terrible idea for mobile devices though...
        seanmcdirmid 8y ago
        That would only work if it isn’t shared with unsafe code.
heydenberk 8y ago
nice
nojvek 8y ago
Love V8's focus on performance, security and memory usage. They really keep on pushing the bar.

103 points by stablemap 8y ago

Interested in those WebAssembly updates, hopefully someday Electron will see more WebAssembly usage (maybe mostly for games?) which should be interesting. I wonder if Kotlin will ever focus on running on WebAssembly.

Avamander 8y ago
I'm interested in seeing a whole new world of wasm exploits. I have a strong suspicion we're going to see the same types of bugs we're seeing with C and C++ in browsers which sounds a bit scary to be honest.
- deweller 8y ago
  I'm sure there will be exploits, as the attack surface will become bigger. But isn't wasm designed from the ground up to be sandboxed in a certain memory space? And won't that prevent buffer overruns from gaining access to other parts of the browser?
  - pjmlp 8y ago
    Yes it is sanboxed, but the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled.
    - magicalist 8y ago
      > the memory inside of a WebAssembly module can still be corrupted, specially if it was compiled from any language without bounds checking enabled. it can be, but there are large classes of security issues that aren't possible like they usually are with those languages. eg it's not possible to jump to arbitrary locations, you can't write to executable memory, etc. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/
      - pjmlp 8y ago
        Still not having bounds protection is a very big one, and 40 years of CVE history doesn't help.
        vardump 8y ago
        WebAssembly does have bounds checking, you can't write outside the designated memory block. On 64-bit systems with virtual address space to spare, you can offload bounds checking to MMU by memory mapping 2 GB+ protection zone both below and above the exposed memory region. If you then limit all pointers/offsets to 32-bit, there should be no direct way to corrupt anything else. You can't reach anything interesting within 32-bit offsets. Of course one can corrupt WebAssembly instance memory all they want, but it won't matter. Performance and security win. Left CPU bugs outside consideration, hopefully those can be addressed in WASM codegen. Not like it's that different from current Javascript JIT cases.
        pjmlp 8y ago
        The memory block contains all data together in well, a block, thus you can happily overwrite two neighbouring arrays, unless I am missing something here WebAssembly does not have fat pointers.
        vardump 8y ago
        Sure, you can corrupt all the data in your instance. You can't overwrite code or the true call stack, so what's the (security) risk?
        pjmlp 8y ago
        Funny question, basically with corrupted data anything goes. For a very extreme convoluted example, maybe that value given back to the JavaScript layer will trigger a patient death by sending the wrong value to their insulin device monitor. But yeah, code and true call stack will be perfectly safe.
- stcredzero 8y ago
  It's also true that some huge fraction of Dalvik/Android exploits were based on the same sorts of optimizations which can be used to make wasm faster.
- rightbyte 8y ago
  I got this feeling that the main selling point of wasm will be "certified" software with some middle man and control. An analogy would be Google's push for https, for our own best ofc.
  - AgentME 8y ago
    WebAssembly works pretty much like Javascript: it doesn't have any new platform APIs, browsers can execute it without special permissions, it can be retrieved from a web server, etc. Any planned lockdown of it would be just as easy to do with javascript.

shawn 8y ago

Built-in functions currently consume 700 KB in each Isolate (an Isolate roughly corresponds to a browser tab in Chrome). This is quite wasteful, and last year we began working on reducing this overhead. In V8 v6.4, we shipped lazy deserialization, ensuring that each Isolate only pays for the built-ins that it actually needs (but each Isolate still had its own copy). Also known as Autoload. What’s old is new again... http://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html http://www.gnu.org/software/emacs/manual/html_node/elisp/Aut... Embedded built-ins go one step further. An embedded built-in is shared by all Isolates, and embedded into the binary itself instead of copied onto the JavaScript heap. This means that built-ins exist in memory only once regardless of how many Isolates are running, an especially useful property now that Site Isolation has been enabled by default. Inb4 security vuln in a builtin is used to pivot across tabs or reveal state in other tabs. Like, say, a timing attack on regex exec to reveal whether the word “Facebook” appears in some other tab. </baseless>

vorpalhex 8y ago
Since you're obviously a savant, it's curious that you don't simply contribute to v8 development given that it's open source.
- shawn 8y ago
  They’ll have to wait in line. My time is far too valuable to give it away. I have tremendous things to accomplish. Actually, I would be surprised if a vuln creeps its way into a builtin. Most of the runtime should be stateless, and regex exec was the only one I could think of that might do some fancy memoization. But I hear it’s fun to collect a paycheck at pwn2own.
- slimsag 8y ago
  I love WebAssembly and I don't agree with GP at all here, but this prevailing holier-than-thou attitude of "You shouldn't complain or poke holes in things unless you're willing to fix them yourself" is just silly, so I down-voted you. Trying to poke holes in things, or raising concerns about them, is contributing. I would rather hear other people's arguments (even if I don't agree with them) than silence them on the grounds of "let's see you do better n00b".

bovermyer 8y ago

This is the bit I'm most interested in: > WebAssembly got a new baseline compiler for much faster startup of complex websites with big WebAssembly modules (such as Google Earth and AutoCAD). Depending on the hardware we are seeing speedups of more than 10×. Stay tuned for more details in a separate blog post.

chacham15 8y ago
I'll be excited about WebAssembly when it can manipulate DOM. Until then, it feels mostly like a thought experiment in that the number of people that it makes sense to use right now is miniscule.
- chinedufn 8y ago
  Check out Rust’s wasm-bindgen - https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen if ya haven’t already. Right now it you call into JS to interact with the DOM but when the host bindings proposal sees fruit it’ll replace the JS shims with direct DOM manipulation!
  - seanmcdirmid 8y ago
    It isn’t clear how they will allow safe access to the DOM without GC. Maybe they’ll take an approach like Microsoft did with UWP and use reference counting?
    - tjallingt 8y ago
      Would be interesting if it would be possible to take the Rust approach and guarantee at parse/compilation time that the DOM interactions are safe without runtime overhead. Probably a terrible idea for mobile devices though...
      - seanmcdirmid 8y ago
        That would only work if it isn’t shared with unsafe code.

heydenberk 8y ago

nice

nojvek 8y ago

Love V8's focus on performance, security and memory usage. They really keep on pushing the bar.