Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WasmEdge

wasmedge.org

Post reply on HN
Print view View original

51–60 of 88 posts

Re: WasmEdge

#51

Post by jeffparsons »

Existenceblinks wrote: post #45

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

My outsider's interpretation is that a lot of the details are being held up while the Component Model spec is finalised, so even if lots of ideas are being bounced around and people are experimenting, we won't see a "Snapshot 2" or many new modules (etc.) until that settles.

After that is done, I'd expect to see a lot of focus shift to fleshing out various WASI APIs, which can then also IINM start to be released individually at their own pace.

Re: WasmEdge

#52

Post by phickey »

jeffparsons wrote: post #51
Existenceblinks wrote: post #45

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

My outsider's interpretation is that a lot of the details are being held up while the Component Model spec is finalised, so even if lots of ideas are being bounced around and people are experimenting, we won't see a "Snapshot 2" or many new modules (etc.) until that settles. After that is done, I'd expect to see a lot of focus shift to fleshing out various WASI APIs, which can then also IINM start to be released indi…

Yep that’s exactly the plan (I work on wasi and the component model and etc)

Re: WasmEdge

#54

Post by jeffparsons »

nerpderp82 wrote: post #2

Given the amount of C++ in this project, I wouldn't run this in an adversarial environment. Meaning, I would not accept untrusted Wasm modules. It is about 100kloc of C/C++ including headers.

C++ _can_ be written safely, as long as the right static and dynamic analysers are used. So while I wouldn't recommend it for _many_ new projects these days, the WasmEdge authors have good reasons to choose C++ and appear to be using it responsibly.

Also, there are so many things that need to be done right for a VM specifically to actually be safe that merely being written in a safer language is lightyears away from being adequate. You _still_ need very careful design, dynamic analysers, and a whole lot of fuzzing if you want to end up with something you can reasonably trust. So if it were written in Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe to use it on untrusted inputs.

I say all this as a huge advocate for Rust in general. Sometimes the less attractive tool is actually a better choice.

Re: WasmEdge

#55

Post by jeffparsons »

phickey wrote: post #52
jeffparsons wrote: post #51

Earlier quoted context omitted.

My outsider's interpretation is that a lot of the details are being held up while the Component Model spec is finalised, so even if lots of ideas are being bounced around and people are experimenting, we won't see a "Snapshot 2" or many new modules (etc.) until that settles. After that is done, I'd expect to see a lot of focus shift to fleshing out various WASI APIs, which can then also IINM start to be released indi…

Yep that’s exactly the plan (I work on wasi and the component model and etc)

Ah, I see, you posted your comment a minute before mine. I got my impression from obsessively reading Zulip threads, pull requests, and meeting minutes. It's nice to hear it from the horse's mouth and not just the tea leaves!

Re: WasmEdge

#57

Post by Existenceblinks »

phickey wrote: post #50
Existenceblinks wrote: post #45

WASI development is very slow. Bytecodealliance is kinda all the big names but it seems not a lot of investment to hire more people working on the spec (I know at some point more people won't work, but right now there are only a few)

I work on Wasi at Fastly, as part of the Bytecode Alliance. WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself. I can’t really say that adding more people would have sped up…

Thanks for the inside. I watched the Component Model repo, it's very active (had to turn off noti).

Still confused why the need for wit file instead of wat directly which is already human-friendly. Now wasm has two versions of text mode?

Appreciated, specification is a hard work.

Re: WasmEdge

#58

Post by kumarski »

jeffparsons wrote: post #49
syrusakbary wrote: post #41

Earlier quoted context omitted.

Interesting. Have you tried to benchmark it also with Wasmer [1]? I'd be curious to see what the timings might be. [1] https://wasmer.io/

I'm impressed — I don't think I've ever seen you miss an opportunity to promote your company. I assume you have some kind of keyword alert set up? Kudos on the mad hustle!

Syrus is a technocrat's technocrat and a big open source contributor. I watch from the sidelines in awe as the community builds wasmer and the wasm ecosystem.

Re: WasmEdge

#59

Post by jetzzz »

If you are running untrusted WASM files with wasmedge be aware that it doesn't sandbox by default. WASM can contain native code that will be executed without sandboxing. From the docs [0][1]:

> The wasmedge CLI tool will execute the WebAssembly in ahead-of-time(AOT) mode if available in the input WASM file.

> The wasmedgec can compile WebAssembly into native machine code (i.e., the AOT compiler). For the pure WebAssembly, the wasmedge tool will execute the WASM in interpreter mode. After compiling with the wasmedgec AOT compiler, the wasmedge tool can execute the WASM in AOT mode which is much faster.

They added an option (--force-interpreter) to disable running untrusted native code [2]:

> Thanks for reporting this. I think we can have a flag to disable the automatically loaded AOT sections from an unknown given universal wasm format. One possible situation is that users want to execute a wasm file with interpreter mode, however, they use a universal wasm format received from a malicious developer, and then the bad thing happens.

[0]: https://wasmedge.org/book/en/cli/wasmedge.html

[1]: https://wasmedge.org/book/en/cli/wasmedgec.html

[2]: https://github.com/WasmEdge/WasmEdge/issues/1631

Re: WasmEdge

#60

Post by phickey »

Existenceblinks wrote: post #57
phickey wrote: post #50

Earlier quoted context omitted.

I work on Wasi at Fastly, as part of the Bytecode Alliance. WASI development has indeed been quite slow. Most of our efforts for the past 2 years have been developing and implementing the Component Model proposal. Right now we are working on porting WASI to the component model, which has been pushing all of the new wit tooling more than it has WASI itself. I can’t really say that adding more people would have sped up…

Thanks for the inside. I watched the Component Model repo, it's very active (had to turn off noti). Still confused why the need for wit file instead of wat directly which is already human-friendly. Now wasm has two versions of text mode? Appreciated, specification is a hard work.

there’s a good write up on this somewhere that you’ll have to forgive me not being able to find tonight on mobile. In general, we want the wat syntax to mirror the binary format very closely, but that’s often at odds with a surface syntax that promotes good software engineering or good developer ux. Two cases for that off the top of my head:

* the component model wat can represent interfaces, but it can’t represent the composition of interfaces, e.g. if we were writing a new interface which opened something file-like and wanted to reuse the oflags type from wasi-filesystem, there would be no way to express that indirectly because we insist wasm binaries are self contained (don’t require you to load other resources), so the oflags type definition would need to be copied in literally.

* when we add resource types back to wit syntax (you can rewind history in wit-bindgen 2 months to find examples, we got rid of them because they were a strawman and now something quite similar is getting speced) it’s nice to have wit syntax appear just like constructors and methods, even if we all know a method desugars to a functions that take a resource as it’s first parameter in the canonical abi. It’s nice to have a distinction in wit that can be used by code generators for creating idiomatic C++, Rust, JS etc methods. Even if we give methods a faithful wat/binary repr (like, e.g. flag types, which are a shorthand for a struct full of bools), the wat/binary form will necessarily have much worse syntax than the wit will, and we think having a syntax that doesn’t send you rubbing your temples reading the component model spec will help adoption.

Speaking as someone who has had to read and write a nontrivial amount of wat over the last 5 years, it’s lovely for small examples and it’s pretty challenging for large, “real world” programs.

Post reply on HN