
V8 release v6.9 - stablemap
https://v8project.blogspot.com/2018/08/v8-release-69.html
======
bovermyer
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
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.

~~~
vardump
The possibility of WebAssembly becoming tangled with complicated web browsers
worries me.

Whatever DOM manipulation there may be in the future, I hope there'll be no
tight coupling with DOM, GC or anything else.

If tight coupling can be avoided, WebAssembly could become lingua franca of
binary formats also outside web.

For things like architecture agnostic plugins, extensions and high performance
light weight "scripting" support.

~~~
steveklabnik
It's called the "host bindings" proposal because the proposal is to create
bindings to the host environemnt; for a browser that's the DOM, for for any
other host, it could be other things. It's not tightly coupled to them.

~~~
vardump
> It's not tightly coupled to them.

Hopefully it'll stay that way.

Dependencies on DOM or Javascript would be devastating for WebAssembly use
outside web browsers.

~~~
steveklabnik
Everyone[1] who works on wasm cares about the non-browser use-case, so I think
you can sleep easy here.

1: Okay so, what I really mean is, "I spend a lot of time talking to people
working on WebAssembly and they've all expressed that to me but of course I
hvaen't talked to literally every single last person".

------
giancarlostoro
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
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
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
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
> _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
Still not having bounds protection is a very big one, and 40 years of CVE
history doesn't help.

~~~
vardump
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
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
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
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.

~~~
vardump
One day a random bit flip in a web app on a non ECC-protected iPad *
controlling a life-critical system will kill a person.

It's just a matter of time.

* Or any other device with data corrupting hardware or software issues.

~~~
pjmlp
Yep it is just a matter of time.

Successful lawsuits against insecure software need to become a common event
until most companies actually start paying attention to their technology stack
and development processes.

------
shawn
_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/Aut...](http://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html)

 _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>

~~~
dividuum
> Inb4 security vuln in a builtin is used to pivot across tabs or reveal state
> in other tabs.

Although I don't know all the internals of how chrome isolates tabs, I'm not
sure how that's supposed to happen. If I understand the original approach
correctly, it just means that the code is in the original binary, paged in
once and using copy-on-write semantics while forking individual sandbox
processes only exists as a single copy instead of multiple copies that would
happen if the code somehow has to be prepared by "copying to the JS heap" of
each individual sandbox process.

~~~
gsnedders
Yes, this is my understanding of the implementation.

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

------
heydenberk
nice

