tschneidereit
Joined 12 years ago
Karma
131
Submissions
40
Member since
Oct 23
WebAssembly & Components & WASI @ Akamai. Started and help lead the Bytecode Alliance.
View on Hacker NewsRecent submissions
Comment · 4 months ago
Oh, no worries at all—it happens!
Comment · 5 months ago
[Creator of the StarlingMonkey JS runtime here]
> It works in the browser already, by bundling another browser runtime engine into wasm.
Note that that's not how JCO works: JCO unbundles a Component, emitting core wasm modules plus JS glue code. JCO also is a toolchain that can orchestrate turning JS into a Component, and that does bundle a JS runtime (StarlingMonkey), but that's not for running Components in JS/browsers, but for running JS in Component runtimes, such as Wasmtime.
Comment · 4 years ago
Oh, no worries at all!
While there was no acquisition involved, a whole group of folks working on WebAssembly at Mozilla (myself included) moved to Fastly last Fall. What I tried to emphasize is that instead of the projects at hand here being open source because they somehow had to be, we all joined Fastly because it's a place where this kind of project can be made open source (and be created in the first place!) :)
Comment · 4 years ago
It's really the other way around: we joined Fastly because we knew it's a place where we could do this kind of work in the open.
None of the code involved here existed a year ago, and none of it was somehow forced to be open source. (Also, the code in these two repositories is in many ways the most boring part of this solution. See this blog post for an excellent overview of the more interesting parts: https://bytecodealliance.org/articles/making-javascript-run-...)
Comment · 7 years ago
That is how we support references in the Rust toolchain right now, via wasm-bindgen, and it's an important part of making unforgable references work for languages that rely on linear memory.
It doesn't help with making capabilities more fine-grained, though: we have to treat all code that has access to that table as having the same level of trust.
Comment · 7 years ago
Agreed, and there are a lot of UX questions to sort out. Many security concepts took many attempts to figure out in full (or to the extent that they have been figured out :))
One important aspect here is that this doesn't just target whole apps. It also targets developers using dependencies: while it's desirable to restrict an application's capabilities, there's a lot of value in developers only giving packages they depend on very limited sets of capabilities. And that seems much more tractable, given that kitchen-sink packages aren't what most people want to use anyway.
Comment · 7 years ago
Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)
Comment · 7 years ago
What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc
For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether.
Since we want to support those languages as first-class citizens, we can't require GC support as a base concept, so we have to treat a nanoprocess as the unit of isolation from the outside.
Once we have GC support, nothing will prevent languages that can use it from expressing finer-grained capabilities even within a nanoprocess, and that seems highly desirable indeed.
(full disclosure: I'm a Mozilla employee and one of the people who set up the Bytecode Alliance.)
Comment · 7 years ago
To expand on this, capabilities allow us to go further than pledge(2): it enables selective forwarding of capabilities to other nanoprocesses, such as only forwarding a handle to a single file out of a directory, or a read-only handle from a read-write one, etc...
Comment · 7 years ago
And Wasmtime will also support both of those. Support for environments in which JITting is not an option is of course really important to this!
Comment · 7 years ago
We're working on that, too :) See this post from last Fall where we laid out a way to think about where WebAssembly is going, which use cases to enable, and how:
https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu...
Comment · 7 years ago
Good news: we fully agree with these goals!
On 1, the libc we're working on[1] is based on musl. It won't ever be 100% compatible with all code, because that runs into constraints imposed by our security goals, but the vast majority of code should eventually just compile when targeting this. (Eventually, because this is all early days.)
On 2, yes, that is explicitly the goals. I'd add that it's not just about OSes, but also about platforms and hardware form factors.
Comment · 7 years ago
Oh, this is amazing!
Comment · 7 years ago
Yes!
Comment · 7 years ago
We've mainly based the current design on CloudABI/Capsicum, but it's all early days, and Fuchsia is on our list of systems to at the very least take heavy inspiration from :)