Live data from Hacker News

Standardizing WASI: A system interface to run WebAssembly outside the web

hacks.mozilla.org

201–210 of 238 posts

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#201

Earlier quoted context omitted.

Look at it this way, this won't cause any harm and there's some chance that it will develop into something useful and successful. Right now there's no reason to conclude that this will turn into something that's no better than Java.

Has a single sandbox ever been written that has not had an escape vulnerability? I don't know of any. Sandboxes aren't safe, and everyone thinks of them as being a perfect prophylactic when they provably, demonstrably, and historically are not, in any way. the solution is not to create another sandbox to run software in.

Okay, I'll bite, what's the solution then? Personally, I don't have any novel software ideas lying around that are demonstrably better than what is proposed by WASI.

One advantage in this new push to build another sandbox is that Rust is leading the charge and is the de facto language of choice when building a greenfield WASM project. Given its propensity for memory safety and WASI's emphasis on capability-oriented security, I think the WASI team has a good chance of building something with a lot of value. Nothing here is novel (except perhaps Rust's extreme prioritization of memory safety) but that doesn't mean it can't or won't be an improvement over prior attempts.

I wonder how many of the previous sandbox vulnerabilities were viable due to some quirky memory manipulation techniques? Quite a few I would imagine.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#202

Earlier quoted context omitted.

.NET's '10 tonne' standard library is a decent part of what makes it so usable. And it's not exactly massive either - I can publish a standalone .NET Core app that's only around 30MB in size. For the usability and GC, I'll take that over C any day.

> I can publish a standalone .NET Core app that's only around 30MB in size. Honestly, it shouldn't need to be that big. There's plenty of cruft even in .NET core.

That will probably come done quiet a bit when illink gets out of alpha. It is basically a tree-shaker to eliminate dead/unused stuff from the resulting standalone binary.

https://github.com/dotnet/announcements/issues/30

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#203

Earlier quoted context omitted.

Except entirely irrelevant as WASM is not Javascript.

Can you show me an example of a WebAssembly app that runs in the browser with JavaScript enabled?

There are probably newer examples, but from when WebAssembly was coming out:

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... (from https://www.webassemblygames.com/ )

https://alpha.iodide.io/

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

https://github.com/mdn/webassembly-examples/

https://github.com/emscripten-core/emscripten/wiki/Porting-E...

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#204

Earlier quoted context omitted.

Can you show me an example of a WebAssembly app that runs in the browser with JavaScript enabled?

There are probably newer examples, but from when WebAssembly was coming out: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... (from https://www.webassemblygames.com/ ) https://alpha.iodide.io/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... https://github.com/mdn/webassembly-examples/ https://github.com/emscripten-core/emscripten/wiki/Porting-E...

Meant to say with JavaScript disabled.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#205

Earlier quoted context omitted.

No, they aren't. They are a variety of distribution mechanisms, which WASI is not and does not contain. Also, WASI is literally fragmented by design. It does not have a singular target, it instead is a bunch of modules (aka, shared libraries), and what modules you get and how they behave is up to the platform. Real native has already long since solved distribution, dependency management, and portable abstractions. WA…

Which nonproprietary plattform can I use today, to reach the widest audience?

Not a useful question to ask or answer, as the answer is either anything or nothing depending on how nitpicky you want to get or where you feel like drawing an arbitrary line.

For example do you consider C++ on Windows to be a proprietary platform, even though C++'s STL isn't proprietary? If so, then WASI on Windows must also be proprietary, no? And if you don't consider C++ to be proprietary, then, you know, you can pick just about anything. They almost all have a standard library that abstracts OS differences and are generally portable.

All that aside, .NET Core is MIT license and already exists. So you can literally be non-proprietary, multi-platform, single-binary today with a mature ecosystem, language & library support, and tooling.

Also in the context of shipping apps let's not forget that this isn't really viable on the 2 biggest consumer app platforms, iOS (no JIT) & Android (majority APIs require Java interop), and for games it's also not viable on the other dominant platforms in those markets - Xbox One & PS4.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#206
post #42

Earlier quoted context omitted.

AS/400 TIMI comes to mind, and CLR as well.

CLR sandbox should not be considered a meaningful security boundary at this point. CAS and partial trust are both officially obsolete. The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they'r…

And WASM remains to be battle tested in the wild, as in the juicy target of millions of black hats out there.

Forcing internal corruption of code produced from C compilers (like doing a stack out of bounds data overwrite due to incorrenct params size) is perfectly viable.

Yeah the exploit doesn't leave the sandbox, so what. It can still be used to direct the sandboxed code to produce other outcome from the called functions.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#207

Earlier quoted context omitted.

For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?

Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?

Ah, just like JavaCard.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#208

Earlier quoted context omitted.

This. I don't have a clear enough mental model for either docker or wasm+wasi, but I immediately thought of docker. What is docker except a bunch of purpose build operating system instances? And why do we need Linux installations (as much as I am a fan of Linux) when we could just run on WASI? And Electron, where each instance runs on an individual instance of a browser?

This is the same reason that things like unikernels have been built for. They haven't taken off because of how difficult it is to rebuild your application to also contain it's kernel, but this kind of sandboxing with WASM and WASI doesn't require that and could likely make things a lot simpler to deal with.

Yep, just like JEE servers deployed bare metal, oh wait.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#209
post #102

Earlier quoted context omitted.

Does it matter? I don't really see the issue with competing standards if the standards are open: The "best" (for some definition of best) should win out eventually. Anything other than Electron if it comes to it

We could re-implement C as well, but is it sensible if we already have C? If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here. As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely…

Is it just me, or do I kinda feel the jvm running on wasm already? Even the uis would work by rendering via canvas in software ...

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#210
post #126

Earlier quoted context omitted.

(1) could be resolved by shipping Java, let's say hypothetically. (2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).

The JVM was designed as a compile target for a very particular kind of language. One with a Java-like object model, with some later concessions for more dynamic languages. C, C++, Rust, etc. do not fit into that model at all. There's a lot of software written in C, and there's a lot of performance to be gained by dropping down to that level when necessary.

By later concessions do you mean invokedynamic? How much did it help? Clojure doesn't use it even now, 8 years after it came about, I think. Is it mostly for JRuby?

The JVM is (and was from the start) a lot more dynamic than Java.

Post reply on HN