|
|
Subscribe / Log in / New account

Announcing the Bytecode Alliance

[Posted November 13, 2019 by ris]

The Bytecode Alliance is an industry partnership with the aim of forging WebAssembly’s outside-the-browser future by collaborating on implementing standards and proposing new ones. The newly formed alliance has "a vision of a WebAssembly ecosystem that is secure by default, fixing cracks in today’s software foundations". The alliance is currently working on a standalone WebAssembly runtime, two use-case specific runtimes, runtime components, and language tooling.
to post comments

Announcing the Bytecode Alliance

Posted Nov 13, 2019 19:58 UTC (Wed) by Kamilion (guest, #42576) [Link] (2 responses)

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.

Announcing the Bytecode Alliance

Posted Nov 14, 2019 12:05 UTC (Thu) by Kamiccolo (subscriber, #95159) [Link]

At least they have pretty illustrations... :}

Announcing the Bytecode Alliance

Posted Nov 15, 2019 20:46 UTC (Fri) by Lennie (subscriber, #49641) [Link]

Have you ever seen this ?:

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

Announcing the Bytecode Alliance

Posted Nov 13, 2019 22:01 UTC (Wed) by ballombe (subscriber, #9523) [Link] (4 responses)

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

Announcing the Bytecode Alliance

Posted Nov 13, 2019 22:38 UTC (Wed) by heftig (subscriber, #73632) [Link] (2 responses)

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

Posted Nov 14, 2019 16:35 UTC (Thu) by mageta (subscriber, #89696) [Link]

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

Posted Nov 14, 2019 23:09 UTC (Thu) by flussence (guest, #85566) [Link]

>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

Posted Nov 14, 2019 21:28 UTC (Thu) by roc (subscriber, #30627) [Link]

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?

Posted Nov 14, 2019 21:28 UTC (Thu) by yodermk (subscriber, #3803) [Link] (12 responses)

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.

Use case?

Posted Nov 15, 2019 12:30 UTC (Fri) by eru (subscriber, #2753) [Link]

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).

Portable low-level *compiled* code

Posted Nov 15, 2019 12:55 UTC (Fri) by CChittleborough (subscriber, #60775) [Link] (10 responses)

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.

Portable low-level *compiled* code

Posted Nov 15, 2019 22:52 UTC (Fri) by atai (subscriber, #10977) [Link] (9 responses)

Here come projects to implement WebAssembly in hardware...

Portable low-level *compiled* code

Posted Nov 15, 2019 23:05 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

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

Portable low-level *compiled* code

Posted Nov 16, 2019 16:09 UTC (Sat) by eru (subscriber, #2753) [Link] (2 responses)

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

Portable low-level *compiled* code

Posted Nov 16, 2019 16:38 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

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

Posted Nov 16, 2019 18:40 UTC (Sat) by eru (subscriber, #2753) [Link]

Interesting, thanks!

Portable low-level *compiled* code

Posted Nov 18, 2019 15:16 UTC (Mon) by ballombe (subscriber, #9523) [Link] (3 responses)

Does it have break; and continue; ?

Portable low-level *compiled* code

Posted Nov 18, 2019 16:35 UTC (Mon) by excors (subscriber, #95769) [Link] (2 responses)

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

Posted Nov 18, 2019 22:50 UTC (Mon) by ballombe (subscriber, #9523) [Link] (1 responses)

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

Portable low-level *compiled* code

Posted Nov 19, 2019 5:49 UTC (Tue) by eru (subscriber, #2753) [Link]

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

Posted Nov 16, 2019 18:30 UTC (Sat) by thoughtpolice (subscriber, #87455) [Link]

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!

The Elephant in the Sandbox

Posted Nov 17, 2019 16:12 UTC (Sun) by hannada (guest, #4633) [Link] (4 responses)

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?

The Elephant in the Sandbox

Posted Nov 17, 2019 16:46 UTC (Sun) by bof (subscriber, #110741) [Link]

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

Posted Nov 17, 2019 17:14 UTC (Sun) by micka (subscriber, #38720) [Link]

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

Posted Nov 17, 2019 19:12 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

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

The Elephant in the Sandbox

Posted Nov 18, 2019 8:30 UTC (Mon) by roc (subscriber, #30627) [Link]

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.)


Copyright © 2019, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds