LWN: Comments on "Announcing the Bytecode Alliance"

Portable low-level compiled code

eru — Tue, 19 Nov 2019 05:49:53 +0000

There does not appear to be any dedicated exception handling, so implementing that (or throw...catch) must be quite kludgy.

Portable low-level compiled code

ballombe — Mon, 18 Nov 2019 22:50:48 +0000

And yet arbitrary setjmp/longjmp work (yes I tested).

Portable low-level compiled code

excors — Mon, 18 Nov 2019 16:35:58 +0000

According to https://webassembly.github.io/spec/core/syntax/instructio... a program consists of well-nested block..end/loop..end/if..end instructions. The br instruction can refer to any block/loop/if that it's nested under; for block/if it behaves like C's break (jumping to the end of the block), for loop it behaves like C's continue (jumping back to the start). If you want to compile a C loop that contains both break and continue, I guess you'd need a "(block (loop (...)))" to allow br in both directions. It looks like switch statements get implemented as a nested stack of blocks (roughly one per case), and then a br_table instruction that dynamically chooses which level of block to break out of, so that it's still nesting-based control flow.

Portable low-level compiled code

ballombe — Mon, 18 Nov 2019 15:16:56 +0000

Does it have break; and continue; ?

The Elephant in the Sandbox

roc — Mon, 18 Nov 2019 08:30:32 +0000

There are two parts to sandbox security:
1) Sandboxing the executed code (e.g. so it can't touch arbitrary memory or achieve unsupervised code execution)
2) Securing the *APIs* that it uses to talk to the world outside the sandbox.

Java's problems were mostly in part #2.

#2 is mostly outside the scope of WebAssembly proper, but in the context of browser-hosted WebAssembly, those APIs are almost exactly just the APIs that the browser already exposes to JS. Thus, WebAssembly doesn't add new attack surface there. (In contrast, PNaCl did add a lot of new attack surface via the Pepper API, which is one reason non-Chromium browser vendors didn't want PNaCl.)

The Elephant in the Sandbox

Cyberax — Sun, 17 Nov 2019 19:12:39 +0000

JVM was just badly designed. It security model was also stupid (granting privileged access to pieces of _code_).

The Elephant in the Sandbox

micka — Sun, 17 Nov 2019 17:14:37 +0000

Have you disabled Javascript execution in your web browser?
If so (AFAIK) you won't have wasm execution.
if not wasm executes with the same constraints in the same sandbox as js (actually there are more constraints like no DOM).

The Elephant in the Sandbox

bof — Sun, 17 Nov 2019 16:46:05 +0000

It's been long enough that a new generation of corporates and their teams, is willing to make the same mistakes again? Or maybe - but I'm super sceptical too - willing to say "NO" often enough to avoid them?

The CVEs of the 20ies will tell.

The Elephant in the Sandbox

hannada — Sun, 17 Nov 2019 16:12:57 +0000

If sand-boxed JVM for the Web was never made adequately safe for general use, how could sand-boxed WebAssembly do any better? As documented on LWN, most browsers disabled support for Java Web Applications years ago, as intolerably risky when run from the open Internet. What reason is there to believe that WebAssembly will fare better? Have I missed something?

Portable low-level compiled code

eru — Sat, 16 Nov 2019 18:40:35 +0000

Interesting, thanks!

Portable low-level compiled code

thoughtpolice — Sat, 16 Nov 2019 18:30:15 +0000

WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing a register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' the table to work around. (Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that.)

But then you're just implementing a compiler. At that point, you might as well call a spade a spade, and just generate code for a target that actually can be implemented efficiently in hardware. Though WASM is small and has fully specified semantics, so you can potentially do that in a trusted codebase at a transparent level (firmware) that would make the distinction a little less important anyway. And if you make that transparent, you have a level of hardware independence where you can play with performance improvements you couldn't safely try in a more general purpose CPU. Long live AS/400, I suppose!

Portable low-level compiled code

excors — Sat, 16 Nov 2019 16:38:48 +0000

There is some discussion at https://medium.com/leaningtech/solving-the-structured-con... . It looks like the naive approach is that any arbitrary control flow graph (including uses of goto) can be translated into a giant looped switch statement, where each case is a basic block and you use a label variable to select which case to run next. That should work for any C code, but performance won't be great. Emscriptem's Relooper algorithm tries to recognise control flow patterns that can be represented more efficiently as regular loops etc, then falls back to the naive approach in more complex cases. The Stackifier algorithm does something cleverer, and there's probably room to invent even better algorithms.

Portable low-level compiled code

eru — Sat, 16 Nov 2019 16:09:42 +0000

But C and C++ do have goto statements. How does an implementation targeting WebAssembly deal with those?

Portable low-level compiled code

Cyberax — Fri, 15 Nov 2019 23:05:49 +0000

Won't really happen. WebAssembly doesn't have goto statements, for example.

Portable low-level compiled code

atai — Fri, 15 Nov 2019 22:52:54 +0000

Here come projects to implement WebAssembly in hardware...

Announcing the Bytecode Alliance

Lennie — Fri, 15 Nov 2019 20:46:29 +0000

Have you ever seen this ?:

https://www.destroyallsoftware.com/talks/the-birth-and-de...

Portable low-level compiled code

CChittleborough — Fri, 15 Nov 2019 12:55:04 +0000

It is important to note that WebAssembly is a moving target. Right now, it is good for arithmetic (integer and floating-point). Work is already under way to properly support structures, references, arrays etc. Separately, the project is developing WASI, which plays similar role to libc in POSIX systems. WASI is intended for tight sandboxing, so it uses capabilities (drawing inspiration from CloudABI and Capsicum) rather than POSIX permissions.

So WASM will one day let you write code in C, C++, Rust etc against WASI and produce .wasm files that (1) can run in any contemporary browser, (2) have great security (enough that you can safely run untrusted .wasm modules) and (3) are relatively easy to translate into optimized machine code. Yes, it is a form of write-once-run-anywhere (‘compile-once-run-anywhere’?) like the JVM, only with less overhead and better performance.

The folks working on WebAssembly realized early on that it would also be very useful outside the browser. For example, once WASM runtimes are widely available, software can be published in compiled form as one set of .wasm files that can be run on most any computer. Smaller project teams such as indy game developers might find this really attractive.

Use case?

eru — Fri, 15 Nov 2019 12:30:27 +0000

The only rationale I can think of is that JVM is not completely universal: it has limitations by design that make implementing C or C++ efficiently hard. On the other hand, that has not prevented using the JVM for a number of other languages (a rather long list at https://en.wikipedia.org/wiki/List_of_JVM_languages).

Then there is Microsoft's CLI (the one originally made for C#), which does support a C++ implementation (by Microsoft), which that should prove it is flexible enough (lit of CLI languages https://en.wikipedia.org/wiki/List_of_CLI_languages). But I guess its association with Microsoft makes people wary of basing open source projects on it (even though there has long been an open-source implementation of the runtime).

Announcing the Bytecode Alliance

flussence — Thu, 14 Nov 2019 23:09:01 +0000

>How many of the processes on your system use more than 4G of virtual memory?

Ironically the only things consuming more than 4GB on mine are also the ones with wasm runtimes. Firefox has a single process consuming 20.6GB vm, and liferea has no less than two hundred and sixty two gigabytes reserved for displaying a dozen RSS feeds. They get very angry and confused when I turn overcommit off.

Announcing the Bytecode Alliance

roc — Thu, 14 Nov 2019 21:28:52 +0000

64-bit is on the roadmap and there doesn't seem to be any major issue blocking it. The sandboxing overhead gets a little bit larger because some of the tricks you can use for 32-bit don't work any more. I think it's just a matter of developer resources and prioritization.

Use case?

yodermk — Thu, 14 Nov 2019 21:28:26 +0000

Not totally sure of the use case of this. I love the idea of WebAssembly in the browser because I'd much rather use C++ than JavaScript for non-trivial code. but outside the browser I can already use C++. How is this different from the JVM .... or any number of other VMs that exist? Maybe "compile once, run anywhere" C++? Ok maybe.....but I'm not seeing a strong use case.

Announcing the Bytecode Alliance

mageta — Thu, 14 Nov 2019 16:35:51 +0000

Processes with more than 4G - or rather 3G, because of the kernel - address space is not nearly as seldom as you seem to think. Linker, Browsers, DBMS, Compressors, even freaking PDF-readers are hoarding address space.

Announcing the Bytecode Alliance

Kamiccolo — Thu, 14 Nov 2019 12:05:40 +0000

At least they have pretty illustrations... :}

Announcing the Bytecode Alliance

heftig — Wed, 13 Nov 2019 22:38:40 +0000

How many of the processes on your system use more than 4G of virtual memory? How many operating systems / distributions still support 32-bit architectures? I don't think it's as much of a barrier as you imply. Support for larger memory spaces can come later.

Announcing the Bytecode Alliance

ballombe — Wed, 13 Nov 2019 22:01:05 +0000

As long as wasm is 32bit only, using it outside the browser will not go far.

Announcing the Bytecode Alliance

Kamilion — Wed, 13 Nov 2019 19:58:32 +0000

Oh. Wonderful. Just what the world needed. Yet another committee designed atrocity with every unpopular kitchen sink option. </XKCD927_Grade_Sarcasm>

On the upside, at least they picked Rust. And then went and implemented their own wacky cross platform libc without first class processes.
So we get the most annoying quirks of POSIX compliance, none of the wonderful libuv goodness, and the bonus feature of timestamps that are intentionally skewed for anti-advertiser privacy, and the security model relies on passing a file descriptor of a directory.
Gee. I wonder what kind of trouble I could get into if that directory was /dev because I was trying to use some tool similar to Balena Etcher?

Even Web-HID and Web-USB doesn't really scare me half as much, since by nature they're limited to certain VID/PID combinations and can't wildcard match.

Looks like it's mostly Fastly pushing forward on this, with Mozilla pushing for Rust, Intel pushing for quirk preservation on their arch and IBM pushing for wider platform support. Including an IoT runtime... that doesn't target FreeRTOS.

*sigh*

I hope this is enough cynicism for everyone else, and y'all can look on the brighter side.

LWN: Comments on "Announcing the Bytecode Alliance"

Portable low-level *compiled* code

Portable low-level *compiled* code

Portable low-level *compiled* code

Portable low-level *compiled* code

The Elephant in the Sandbox

The Elephant in the Sandbox

The Elephant in the Sandbox

The Elephant in the Sandbox

The Elephant in the Sandbox

Portable low-level *compiled* code

Portable low-level *compiled* code

Portable low-level *compiled* code

Portable low-level *compiled* code

Portable low-level *compiled* code

Portable low-level *compiled* code

Announcing the Bytecode Alliance

Portable low-level *compiled* code

Use case?

Announcing the Bytecode Alliance

Announcing the Bytecode Alliance

Use case?

Announcing the Bytecode Alliance

Announcing the Bytecode Alliance

Announcing the Bytecode Alliance

Announcing the Bytecode Alliance

Announcing the Bytecode Alliance

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code

Portable low-level compiled code