9 ms·

WasmEdge

213 points by mkl95 4y ago

nerpderp82 4y ago
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.
- frutiger 4y ago
  I would sincerely be curious to know how many “kloc of C/C++” you are already running in an adversarial environment and how much of a dent this project would make.
  - nerpderp82 4y ago
    How much of a dent (non-quantitative) it would make, depends on how it is deployed. In my environment, the risk of WasmEdge outweighs its advantages. By that argument there is no difference between 80% and 85% or 1% and 2%. One should absolutely reduce their attack surface. If the goal is to be "lightweight" as compared to containers, then WasmEdge would be running as a regular OS process and not in a jail or cgroups container. By construction, WasmEdge has a greater threat model vs rootless containers. I am huge fan of Wasm, but my appreciation for a technology doesn't outweigh the risk posed by the runtime. Its security properties are intractable. Are you saying that end users should overlook this?
    - frutiger 4y ago
      > By construction, WasmEdge has a greater threat model vs rootless containers. Yes — this argument makes a lot more sense to me compared to “kloc of C/C++”.
- juntao 4y ago
  I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons: 1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V. 2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view. It is indeed more challenging to run C++ programs securely. We are participating Google’s OSS-fuzz program. Of course, for application developers, WasmEdge provides “Rust first” SDKs and APIs. Almost all of our new features are available in the Rust SDK first. :)
  - nerpderp82 4y ago
    Besides fuzzing, what other security measures does WasmEdge use? Is it able to use memory protection on platforms where it is available?
- jeffparsons 4y ago
  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.
  - nerpderp82 4y ago
    This response is a mess, I apologize. One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff. I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity. > Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe I never made that argument. But let's say I did. Given two systems, one made in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else? WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge https://app.codecov.io/gh/WasmEdge/WasmEdge Only 80% coverage, not great. I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works. Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz https://github.com/bytecodealliance/wasmtime/tree/main/fuzz In my cursory look at the WasmEdge codebase I see No application UBSan [1] No application of control flow guard [2], either in the build or in the generated LLVM output. Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address 0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard. 309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge. In my cursor look at Wasmtime, I see Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/* The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc. It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure. I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is. Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/ https://mozilla.github.io/cargo-vet/ It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n] [1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html [2] https://www.zdnet.com/article/microsofts-control-flow-guard-comes-to-rust-and-llvm-compilers/ https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html [n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175 https://github.com/lefticus/cpp_weekly/issues/175
cyanydeez 4y ago
Seems like the edge is just SaaS microservices. Change my mind.
- CharlesW 4y ago
  Can you elaborate on the connection as you see it? I think of edge computing, SaaS, and microservices as independent concerns.
  - juntao 4y ago
    They are all outside of traditional mega data centers. :)
- mkl95 4y ago
  I think of the edge as a fancy term for services where minimizing I/O is one of the main goals. Which is sometimes, but not always the case with microservices. (Disclaimer: I'm not associated with this project in any way)
- juntao 4y ago
  I am a maintainer at WasmEdge. :) The name “edge” signifies that it is lightweight. We think it is a lightweight and secure alternative to Linux containers. The application use cases include containerization on edge devices, serverless functions on edge cloud, embedded functions for databases or SaaS, stream functions for data pipelines, or even smart contracts for blockchains. All of the above are “edge” use cases in the sense that they are typically outside of mega data centers. :)
  - joezydeco 4y ago
    How do I use this on a bare metal Cortex-M with no filesystem or networking?
  - Matthias247 4y ago
    Edge typically means that the software is running neither on an end device (e.g. a consumers phone/PC/tablet/TV), nor on the very backend in a big datacenter (like AWS us-east-1 or another region), but somewhere in between. E.g. a "mini-datacenter" close to the user (CDN points-of-presence (POPs) are called edge locations", or some aggregation points in between (e.g. gateway devices in factories that proxy between on-site components and in-cloud components). The term doesn't have a lot to do with how efficient or non-efficient the software that is run in those places is.
laurencerowe 4y ago
Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 Whether it's faster or not really depends on the complexity of what's being run. After reading about wasmtime 1.0's super fast 5 microsecond snapshot restore time (https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...) I did some experiments with QuickJS and Javy which runs QuickJS in wasmtime. Rendering a moderately complex web page with React renderToString production 30kB of html on my MacBook Air M1 took: - Deno first iteration: 12-20ms - Deno subsequent iterations: 2-4ms - qjs native: 18-24ms - javy (qjs wasmtime): 40-60ms I've not tried WasmEdge but it's JS performance would presumably fall somewhere between that of qjs native and under wasmtime. Firecracker claims a ~3ms snapshot restore time on ARM so might be the best way to go currently for such workloads but there is certainly a large subset of problems for which the current performance is adequate. There has been talk of AOT compilation for SpiderMonkey.wasm (https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly https://bytecodealliance.org/articles/making-javascript-run-...) which I hope this will some day happen since it should close the gap substantially. I recently asked on the ByteCode Alliance Zulip but there hasn't yet been any progress and it requires a substantial amount of work.
- azakai 4y ago
  Another thing that would be interesting to measure here is memory usage. QuickJS might be slower (as a minimal interpreter) but at least it should be much smaller than a full optimizing JS engine (running normally or compiled to wasm), both in terms of code size and runtime memory usage. That might matter in some cases.
  - hutzlibu 4y ago
    "at least it should be much smaller than a full optimizing JS engine, both in terms of code size and runtime memory usage" Why should QuickJS use less runtime memory? Genuine question, I just recently learned of QuickJS and what I understand, it is way smaller in itself, meaning you do not need so much memory for the engine itself, but that does not say anything how efficient it is with executing js code. Or are there benchmarks that say, it is also more memory efficient with executing js? Either way, yes, I also think meassuring memory is important.
jedisct1 4y ago
Not Zig bindings yet :(
ridruejo 4y ago
WasmEdge is one of the most exciting Wasm runtimes out there. It is part of the CNCF and does support a bunch interesting functionality (wasi-nn, integration with Docker via runwasi, etc)
- brrrrrm 4y ago
  what's the deal with wasi-nn? (who is supporting it?) Seems super high level and somewhat brittle
  - juntao 4y ago
    Disclaimer: I am a maintainer of WasmEdge. WASI-NN allows Wasm to be a wrapper of native tensor frameworks — very much the same way Python is a wrapper for Tensorflow and PyTorch. The benefit of using Wasm as a wrapper is its high performance (Use Rust to prepare data) and multi language support (inference in JS!) WasmEdge supports Tensorflow, PyTorch, and OpenVINO as wasi-NN backends.
politelemon 4y ago
I got a bit bewildered by the quick start documentation. It starts by showing how to install and uninstall, followed by running it in different execution environments, it seems to be expecting that you already know what wasmedge is. That's unexpected, as usually a quickstart shows how to write and run a simple application.
- juntao 4y ago
  Will improve! Thanks! One of the challenges is that Wasm supports multiple languages. So, we will have to decide to start from a Rust app or a JS app or something else. Would love your suggestions.
  - politelemon 4y ago
    Thanks. I think JS would be a good option since it's a common language for web developers, who are most likely to be the target audience.
  - jvalencia 4y ago
    I've seen multiple docs have a default code area (JS), with tabs for other languages (rust, etc)
pjmlp 4y ago
This was Edge before WASM. https://www.sunspotdev.org/ https://www.sunspotdev.org/ https://www.parallax.com/propeller-multicore-concept/ https://www.parallax.com/propeller-multicore-concept/ https://en.wikipedia.org/wiki/Netduino https://en.wikipedia.org/wiki/Netduino
- juntao 4y ago
  We are hoping to get WasmEdge running on as many IoT devices as possible … We would love to see more containerization on the edge: https://www.cncf.io/blog/2021/11/11/containerization-on-the-edge/ https://www.cncf.io/blog/2021/11/11/containerization-on-the-...
tony-allan 4y ago
Ten minutes into reading the documentation and I believe that this is a really important technology. I can't wait to find how to integrate this into my own code. Impressive and very cool!
Nicole9 4y ago
FYI, the source code is here: https://github.com/WasmEdge/WasmEdge https://github.com/WasmEdge/WasmEdge
alberth 4y ago
The lifecycle of software over the decades: - v1: desktop software (1980-2000) - v2: web software, single tenant, single datacenter - v3: web software, multi-tenant, single data center - v4: web software, multi-tenant, hosted in “cloud” - v5: web software, multi-tenant, hosted on cloud “edge” - v6: electron apps installed “hosted” on desktop (the ultimate cloud edge) Full circle.
- j-pb 4y ago
  Yeah, but we made some awesome sandboxing friends along the way. We could actually get a nice performance boost out of running WASM with VM enforced security instead of Rings and the MMU.[0] [0]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
rafale 4y ago
Why use a WASM VM when there are more mature VMs out there like .net/CLR? What's the benefit?
- juntao 4y ago
  I can think of a few: * Lightweight (no GC, under 2MB) * Designed to be a secure sandbox (not just a language runtime) * Modular (add host functions as needed — eg support for Tensorflow) * Multiple languages (esp compiled languages like Rust) * Works with container tools (Docker, k8s etc)
  - pjmlp 4y ago
    Lightweight (no GC, under 2MB) => Which is why all GC based languages are forced to bring their own GC when targeting WASM. Designed to be a secure sandbox (not just a language runtime) => JVM and CLR also were designed as such. It didn't work out as well as planned, when black hat hackers started researching how to game the sandbox. Still open for WASM. Modular (add host functions as needed — eg support for Tensorflow) => JVM and CLR have dynamic code loading capabilities. WASM still hasn't standardized dynamic linking => Multiple languages (esp compiled languages like Rust) => Just like CLR, hence why it is Common Language Runtime, C and C++ were part of version 1.0 release. Works with container tools (Docker, k8s etc) => Just like JVM and CLR do.
- Deukhoofd 4y ago
  It's ideal for running untrusted code, as it will only be able to access the external functions it's given by the host. This in contrast with other VMs, where you're effectively giving full system access to the VM. Besides that, WASM allows for an open universal standard for VMs. This means that we can easily develop with many different languages for WASM.
Existenceblinks 4y ago
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)
- phickey 4y ago
  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 the last few years. The vision of the component model is very ambitious - it’s the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM, and the security posture supports mutually distrustful components by default. If we had just iterated on the witx version of wasi without coming up with the component model first, I believe both the component model and wasi would be worse off for it. A lot of the foundational spec work and tooling is now (hopefully!) pretty stable. We used to rewrite everything related to the component model (fka interface types or module linking) every 6-9 months because the spec changed really radically, now I genuinely believe you’ll be able to take todays wit-bindgen to production in 6-9 months of polishing. We are approaching the point where we can get those tools in the hands of way more contributors and the ecosystem can grow. So yes, the contributors to it today are small, but they are growing (I’ve spent a big chunk of the last few weeks bringing on more contributors from other bca companies) and soon will be able to grow even more.
  - Existenceblinks 4y ago
    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.
    - 4y ago
admax88qqq 4y ago
> and 20% faster at runtime. That sounds... Untrue.
- 3Sophons 4y ago
  May I ask which sentence are you quoting..
curist 4y ago
Finally a WASM runtime provides a more detailed C API document.
benatkin 4y ago
There's this, too: https://github.com/fermyon/spin https://github.com/fermyon/spin "Spin is an open source framework for building and running fast, secure, and composable cloud microservices with WebAssembly"
- ushakov 4y ago
  They’re VC-funded and their business model is vendor lock-in. See their response to my discussion: https://github.com/fermyon/spin/discussions/861 https://github.com/fermyon/spin/discussions/861 With WasmEdge there is no vendor lock-in
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - mikkelhegn 4y ago
    Hi, Mikkel from Fermyon here. Both Spin and the Fermyon Platform are open-source projects. Fermyon Cloud is a managed service built on top of the Fermyon Platform. In comparison with WasmEdge, the WebAssembly runtime used in Spin is Wasmtime, which is also open sourced and built by the Bytecode Alliance. Hope this expands upon the existing response.
jetzzz 4y ago
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 https://wasmedge.org/book/en/cli/wasmedge.html [1]: https://wasmedge.org/book/en/cli/wasmedgec.html https://wasmedge.org/book/en/cli/wasmedgec.html [2]: https://github.com/WasmEdge/WasmEdge/issues/1631 https://github.com/WasmEdge/WasmEdge/issues/1631
- juntao 4y ago
  Hmm, we allow the CLI to execute AOT code sections embedded in WASM files as a convenience feature -- you can do AOT compilation and then execute it on your CLI. For server side deployment, you should always do the AOT compilation on the server. But I agree this could be more clear. We are adding a new CLI option to disable AOT code segment in the WASM file for people who do not wish to perform the separate AOT compilation step.
supermatt 4y ago
How does this compare to wasmtime, wasmer, etc? Why would I choose one over the other?
- syrusakbary 4y ago
  I've just created a new comparison page analyzing the main differences, hope this helps! https://wasmer.io/wasmer-vs-wasmedge https://wasmer.io/wasmer-vs-wasmedge
  - supermatt 4y ago
    While I appreciate your comparison pages for highlighting the strengths of wasmer, they really do avoid talking about any of the metrics where wasmer isnt top performer. IMHO this doesnt really give me the information I need to make a decision. For example, the wasmedge website claims it is the fastest runtime but I notice that your comparison page doesnt mention runtime performance at all. It would be nice to know how much slower is wasmer in that respect. I feel that if wasmer covered things like this in the comparisons, and was highlighting that its only X% slower (even though thats a negative) I could balance the positives accordingly when making a decision about which runtime to choose. There doesnt seem to be anywhere that provides an unbiased comparison. Maybe wasmer could lead the charge in that respect?
    - syrusakbary 4y ago
      > For example, the wasmedge website claims it is the fastest runtime but I notice that your comparison page doesnt mention runtime performance at all. It would be nice to know how much slower is wasmer in that respect. The places where there are no differences between runtimes are not showcased in the shared page intentionally. Runtime performance it's not hidden because Wasmer is slower, it's hidden because there should be little difference on runtime performance between both runtimes. But just to be clear, Wasmer (when used with LLVM) should be as fast (if not faster) than WasmEdge on runtime performance. As a random fact: Wasmer 3.0 uses zero-copy deserialization mechanisms that are not yet implemented by any other runtime. So I bet my horses that Wasmer running a pre-compiled Wasm module is not just at-level with WasmEdge but probably faster :) > There doesnt seem to be anywhere that provides an unbiased comparison. Maybe wasmer could lead the charge in that respect? This is a great suggestion, actually.
shanghaikid 4y ago
Although I know it's not WASM's problem, but I really hope WASM can support GRPC.
koyote 4y ago
> Compared with Linux containers, WebAssembly runtimes achieve higher performance with lower resource consumption. I keep seeing this kind of statement, but is it actually true? Are there any good benchmarks around this?
- 3Sophons 4y ago
  WasmEdge contributor here. We had some last year. Paper: A Lightweight Design for High-performance Serverless Computing, published on IEEE Software, Jan 2021. https://arxiv.org/abs/2010.07115 https://arxiv.org/abs/2010.07115 Article: Performance Analysis for Arm vs. x86 CPUs in the Cloud, published on infoQ.com, Jan 2021. https://www.infoq.com/articles/arm-vs-x86-cloud-performance/ https://www.infoq.com/articles/arm-vs-x86-cloud-performance/ Source code of test cases: https://github.com/second-state/wasm32-wasi-benchmark https://github.com/second-state/wasm32-wasi-benchmark See if these helps. (Kinda old so will be needing more updated ones)

213 points by mkl95 4y ago

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.

frutiger 4y ago
I would sincerely be curious to know how many “kloc of C/C++” you are already running in an adversarial environment and how much of a dent this project would make.
- nerpderp82 4y ago
  How much of a dent (non-quantitative) it would make, depends on how it is deployed. In my environment, the risk of WasmEdge outweighs its advantages. By that argument there is no difference between 80% and 85% or 1% and 2%. One should absolutely reduce their attack surface. If the goal is to be "lightweight" as compared to containers, then WasmEdge would be running as a regular OS process and not in a jail or cgroups container. By construction, WasmEdge has a greater threat model vs rootless containers. I am huge fan of Wasm, but my appreciation for a technology doesn't outweigh the risk posed by the runtime. Its security properties are intractable. Are you saying that end users should overlook this?
  - frutiger 4y ago
    > By construction, WasmEdge has a greater threat model vs rootless containers. Yes — this argument makes a lot more sense to me compared to “kloc of C/C++”.
juntao 4y ago
I am a maintainer of the WasmEdge project. Yes, it is written in C++ for two reasons: 1 C++ apps can run a lot of edge hardware devices and OSes. We are running on RTOS like seL4 and CPUs like RISC-V. 2 There are already two leading Wasm runtimes written in Rust when we started. We thought runtime diversity is important from security and reliability point of view. It is indeed more challenging to run C++ programs securely. We are participating Google’s OSS-fuzz program. Of course, for application developers, WasmEdge provides “Rust first” SDKs and APIs. Almost all of our new features are available in the Rust SDK first. :)
- nerpderp82 4y ago
  Besides fuzzing, what other security measures does WasmEdge use? Is it able to use memory protection on platforms where it is available?
jeffparsons 4y ago
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.
- nerpderp82 4y ago
  This response is a mess, I apologize. One can do lots of things. Yes all of those things are still issues, but in enumerating all the things as you have, you make a compelling argument not to use C++. If one picks something else like SML, Go or even Rust, it allows them to focus on those common areas of correctness and not also, all that other stuff. I don't think you are apologizing for C++, but I hear this a lot, whatabout all the other parts that are fixed by a more sound system? My response is that we only have so many decisions we can make in the day, using a system that removes whole classes of problems allows me to focus on the non-accidental (forced) complexity. > Rust as Wasmtime is, that alone wouldn't actually give me much more confidence that it's safe I never made that argument. But let's say I did. Given two systems, one made in Rust and one made in C++. How do I audit the C++ code to ensure that it has the same level of safety as basically _anything_ else? WasmEdge is using code coverage, good! https://app.codecov.io/gh/WasmEdge/WasmEdge https://app.codecov.io/gh/WasmEdge/WasmEdge Only 80% coverage, not great. I see mention of fuzzing being used, but I only get 69 hits in the codebase for "fuzz" and no documentation about how it actually works. Wasmtime includes documentation on how to use their fuzzer, https://github.com/bytecodealliance/wasmtime/tree/main/fuzz https://github.com/bytecodealliance/wasmtime/tree/main/fuzz In my cursory look at the WasmEdge codebase I see No application UBSan [1] No application of control flow guard [2], either in the build or in the generated LLVM output. Infact the only sanitization flags they are passing are -fsanitize=fuzzer,address 0 mentions of 'control flow' in the WasmEdge codebase, 65 mentions in Wasmtime. Although it doesn't appear that Wasmtime is itself being compiled with cfguard. 309 mention of spectre mitigations in Wasmtime, 1 link to a cloudflare blogpost in WasmEdge. In my cursor look at Wasmtime, I see Much better fuzzing support, 85 uses of unsafe in cranelift itself, 1400+ uses of unsafe in crates/* The changelog and git messages for WasmEdge talk about type errors (those type errors look impossible in Rust), bus errors, out of bounds, etc. It does not inspire confidence. C++ is already starting from behind. This software is targeted to be run on bare metal, embedded and widely distributed. It just doesn't have the level of detail around testing and correctness that I would expect for such a critical piece of infrastructure. I am not saying that Wasmtime does not also have issues, that would be preposterous. But on the face of it, WasmEdge has a lot of work to do to catch up to where Wasmtime already is. Wasmtime appears to care about the security properties of their dependencies with https://mozilla.github.io/cargo-vet/ https://mozilla.github.io/cargo-vet/ It does not look like the WasmEdge project applies this basic list of practices as outlined by Jason Turner [n] [1] https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html [2] https://www.zdnet.com/article/microsofts-control-flow-guard-comes-to-rust-and-llvm-compilers/ https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html https://clang.llvm.org/docs/ControlFlowIntegrity.html [n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175 https://github.com/lefticus/cpp_weekly/issues/175

cyanydeez 4y ago

Seems like the edge is just SaaS microservices. Change my mind.

CharlesW 4y ago
Can you elaborate on the connection as you see it? I think of edge computing, SaaS, and microservices as independent concerns.
- juntao 4y ago
  They are all outside of traditional mega data centers. :)
mkl95 4y ago
I think of the edge as a fancy term for services where minimizing I/O is one of the main goals. Which is sometimes, but not always the case with microservices. (Disclaimer: I'm not associated with this project in any way)
juntao 4y ago
I am a maintainer at WasmEdge. :) The name “edge” signifies that it is lightweight. We think it is a lightweight and secure alternative to Linux containers. The application use cases include containerization on edge devices, serverless functions on edge cloud, embedded functions for databases or SaaS, stream functions for data pipelines, or even smart contracts for blockchains. All of the above are “edge” use cases in the sense that they are typically outside of mega data centers. :)
- joezydeco 4y ago
  How do I use this on a bare metal Cortex-M with no filesystem or networking?
- Matthias247 4y ago
  Edge typically means that the software is running neither on an end device (e.g. a consumers phone/PC/tablet/TV), nor on the very backend in a big datacenter (like AWS us-east-1 or another region), but somewhere in between. E.g. a "mini-datacenter" close to the user (CDN points-of-presence (POPs) are called edge locations", or some aggregation points in between (e.g. gateway devices in factories that proxy between on-site components and in-cloud components). The term doesn't have a lot to do with how efficient or non-efficient the software that is run in those places is.

laurencerowe 4y ago

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 Whether it's faster or not really depends on the complexity of what's being run. After reading about wasmtime 1.0's super fast 5 microsecond snapshot restore time (https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...) I did some experiments with QuickJS and Javy which runs QuickJS in wasmtime. Rendering a moderately complex web page with React renderToString production 30kB of html on my MacBook Air M1 took: - Deno first iteration: 12-20ms - Deno subsequent iterations: 2-4ms - qjs native: 18-24ms - javy (qjs wasmtime): 40-60ms I've not tried WasmEdge but it's JS performance would presumably fall somewhere between that of qjs native and under wasmtime. Firecracker claims a ~3ms snapshot restore time on ARM so might be the best way to go currently for such workloads but there is certainly a large subset of problems for which the current performance is adequate. There has been talk of AOT compilation for SpiderMonkey.wasm (https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly https://bytecodealliance.org/articles/making-javascript-run-...) which I hope this will some day happen since it should close the gap substantially. I recently asked on the ByteCode Alliance Zulip but there hasn't yet been any progress and it requires a substantial amount of work.

azakai 4y ago
Another thing that would be interesting to measure here is memory usage. QuickJS might be slower (as a minimal interpreter) but at least it should be much smaller than a full optimizing JS engine (running normally or compiled to wasm), both in terms of code size and runtime memory usage. That might matter in some cases.
- hutzlibu 4y ago
  "at least it should be much smaller than a full optimizing JS engine, both in terms of code size and runtime memory usage" Why should QuickJS use less runtime memory? Genuine question, I just recently learned of QuickJS and what I understand, it is way smaller in itself, meaning you do not need so much memory for the engine itself, but that does not say anything how efficient it is with executing js code. Or are there benchmarks that say, it is also more memory efficient with executing js? Either way, yes, I also think meassuring memory is important.

jedisct1 4y ago

Not Zig bindings yet :(

ridruejo 4y ago

WasmEdge is one of the most exciting Wasm runtimes out there. It is part of the CNCF and does support a bunch interesting functionality (wasi-nn, integration with Docker via runwasi, etc)

brrrrrm 4y ago
what's the deal with wasi-nn? (who is supporting it?) Seems super high level and somewhat brittle
- juntao 4y ago
  Disclaimer: I am a maintainer of WasmEdge. WASI-NN allows Wasm to be a wrapper of native tensor frameworks — very much the same way Python is a wrapper for Tensorflow and PyTorch. The benefit of using Wasm as a wrapper is its high performance (Use Rust to prepare data) and multi language support (inference in JS!) WasmEdge supports Tensorflow, PyTorch, and OpenVINO as wasi-NN backends.

politelemon 4y ago

I got a bit bewildered by the quick start documentation. It starts by showing how to install and uninstall, followed by running it in different execution environments, it seems to be expecting that you already know what wasmedge is. That's unexpected, as usually a quickstart shows how to write and run a simple application.

juntao 4y ago
Will improve! Thanks! One of the challenges is that Wasm supports multiple languages. So, we will have to decide to start from a Rust app or a JS app or something else. Would love your suggestions.
- politelemon 4y ago
  Thanks. I think JS would be a good option since it's a common language for web developers, who are most likely to be the target audience.
- jvalencia 4y ago
  I've seen multiple docs have a default code area (JS), with tabs for other languages (rust, etc)

pjmlp 4y ago

This was Edge before WASM. https://www.sunspotdev.org/ https://www.sunspotdev.org/ https://www.parallax.com/propeller-multicore-concept/ https://www.parallax.com/propeller-multicore-concept/ https://en.wikipedia.org/wiki/Netduino https://en.wikipedia.org/wiki/Netduino

juntao 4y ago
We are hoping to get WasmEdge running on as many IoT devices as possible … We would love to see more containerization on the edge: https://www.cncf.io/blog/2021/11/11/containerization-on-the-edge/ https://www.cncf.io/blog/2021/11/11/containerization-on-the-...

tony-allan 4y ago

Ten minutes into reading the documentation and I believe that this is a really important technology. I can't wait to find how to integrate this into my own code. Impressive and very cool!

Nicole9 4y ago

FYI, the source code is here: https://github.com/WasmEdge/WasmEdge https://github.com/WasmEdge/WasmEdge

alberth 4y ago

The lifecycle of software over the decades: - v1: desktop software (1980-2000) - v2: web software, single tenant, single datacenter - v3: web software, multi-tenant, single data center - v4: web software, multi-tenant, hosted in “cloud” - v5: web software, multi-tenant, hosted on cloud “edge” - v6: electron apps installed “hosted” on desktop (the ultimate cloud edge) Full circle.

j-pb 4y ago
Yeah, but we made some awesome sandboxing friends along the way. We could actually get a nice performance boost out of running WASM with VM enforced security instead of Rings and the MMU.[0] [0]: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

rafale 4y ago

Why use a WASM VM when there are more mature VMs out there like .net/CLR? What's the benefit?

juntao 4y ago
I can think of a few: * Lightweight (no GC, under 2MB) * Designed to be a secure sandbox (not just a language runtime) * Modular (add host functions as needed — eg support for Tensorflow) * Multiple languages (esp compiled languages like Rust) * Works with container tools (Docker, k8s etc)
- pjmlp 4y ago
  Lightweight (no GC, under 2MB) => Which is why all GC based languages are forced to bring their own GC when targeting WASM. Designed to be a secure sandbox (not just a language runtime) => JVM and CLR also were designed as such. It didn't work out as well as planned, when black hat hackers started researching how to game the sandbox. Still open for WASM. Modular (add host functions as needed — eg support for Tensorflow) => JVM and CLR have dynamic code loading capabilities. WASM still hasn't standardized dynamic linking => Multiple languages (esp compiled languages like Rust) => Just like CLR, hence why it is Common Language Runtime, C and C++ were part of version 1.0 release. Works with container tools (Docker, k8s etc) => Just like JVM and CLR do.
Deukhoofd 4y ago
It's ideal for running untrusted code, as it will only be able to access the external functions it's given by the host. This in contrast with other VMs, where you're effectively giving full system access to the VM. Besides that, WASM allows for an open universal standard for VMs. This means that we can easily develop with many different languages for WASM.

Existenceblinks 4y ago

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)

phickey 4y ago
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 the last few years. The vision of the component model is very ambitious - it’s the first credible open (as in, not owned by Oracle or MS) standard for a real cross language VM, and the security posture supports mutually distrustful components by default. If we had just iterated on the witx version of wasi without coming up with the component model first, I believe both the component model and wasi would be worse off for it. A lot of the foundational spec work and tooling is now (hopefully!) pretty stable. We used to rewrite everything related to the component model (fka interface types or module linking) every 6-9 months because the spec changed really radically, now I genuinely believe you’ll be able to take todays wit-bindgen to production in 6-9 months of polishing. We are approaching the point where we can get those tools in the hands of way more contributors and the ecosystem can grow. So yes, the contributors to it today are small, but they are growing (I’ve spent a big chunk of the last few weeks bringing on more contributors from other bca companies) and soon will be able to grow even more.
- Existenceblinks 4y ago
  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.
  - 4y ago

admax88qqq 4y ago

> and 20% faster at runtime. That sounds... Untrue.

3Sophons 4y ago
May I ask which sentence are you quoting..

curist 4y ago

Finally a WASM runtime provides a more detailed C API document.

benatkin 4y ago

There's this, too: https://github.com/fermyon/spin https://github.com/fermyon/spin "Spin is an open source framework for building and running fast, secure, and composable cloud microservices with WebAssembly"

ushakov 4y ago
They’re VC-funded and their business model is vendor lock-in. See their response to my discussion: https://github.com/fermyon/spin/discussions/861 https://github.com/fermyon/spin/discussions/861 With WasmEdge there is no vendor lock-in
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- mikkelhegn 4y ago
  Hi, Mikkel from Fermyon here. Both Spin and the Fermyon Platform are open-source projects. Fermyon Cloud is a managed service built on top of the Fermyon Platform. In comparison with WasmEdge, the WebAssembly runtime used in Spin is Wasmtime, which is also open sourced and built by the Bytecode Alliance. Hope this expands upon the existing response.

jetzzz 4y ago

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 https://wasmedge.org/book/en/cli/wasmedge.html [1]: https://wasmedge.org/book/en/cli/wasmedgec.html https://wasmedge.org/book/en/cli/wasmedgec.html [2]: https://github.com/WasmEdge/WasmEdge/issues/1631 https://github.com/WasmEdge/WasmEdge/issues/1631

juntao 4y ago
Hmm, we allow the CLI to execute AOT code sections embedded in WASM files as a convenience feature -- you can do AOT compilation and then execute it on your CLI. For server side deployment, you should always do the AOT compilation on the server. But I agree this could be more clear. We are adding a new CLI option to disable AOT code segment in the WASM file for people who do not wish to perform the separate AOT compilation step.

supermatt 4y ago

How does this compare to wasmtime, wasmer, etc? Why would I choose one over the other?

syrusakbary 4y ago
I've just created a new comparison page analyzing the main differences, hope this helps! https://wasmer.io/wasmer-vs-wasmedge https://wasmer.io/wasmer-vs-wasmedge
- supermatt 4y ago
  While I appreciate your comparison pages for highlighting the strengths of wasmer, they really do avoid talking about any of the metrics where wasmer isnt top performer. IMHO this doesnt really give me the information I need to make a decision. For example, the wasmedge website claims it is the fastest runtime but I notice that your comparison page doesnt mention runtime performance at all. It would be nice to know how much slower is wasmer in that respect. I feel that if wasmer covered things like this in the comparisons, and was highlighting that its only X% slower (even though thats a negative) I could balance the positives accordingly when making a decision about which runtime to choose. There doesnt seem to be anywhere that provides an unbiased comparison. Maybe wasmer could lead the charge in that respect?
  - syrusakbary 4y ago
    > For example, the wasmedge website claims it is the fastest runtime but I notice that your comparison page doesnt mention runtime performance at all. It would be nice to know how much slower is wasmer in that respect. The places where there are no differences between runtimes are not showcased in the shared page intentionally. Runtime performance it's not hidden because Wasmer is slower, it's hidden because there should be little difference on runtime performance between both runtimes. But just to be clear, Wasmer (when used with LLVM) should be as fast (if not faster) than WasmEdge on runtime performance. As a random fact: Wasmer 3.0 uses zero-copy deserialization mechanisms that are not yet implemented by any other runtime. So I bet my horses that Wasmer running a pre-compiled Wasm module is not just at-level with WasmEdge but probably faster :) > There doesnt seem to be anywhere that provides an unbiased comparison. Maybe wasmer could lead the charge in that respect? This is a great suggestion, actually.

shanghaikid 4y ago

Although I know it's not WASM's problem, but I really hope WASM can support GRPC.

koyote 4y ago

> Compared with Linux containers, WebAssembly runtimes achieve higher performance with lower resource consumption. I keep seeing this kind of statement, but is it actually true? Are there any good benchmarks around this?

3Sophons 4y ago
WasmEdge contributor here. We had some last year. Paper: A Lightweight Design for High-performance Serverless Computing, published on IEEE Software, Jan 2021. https://arxiv.org/abs/2010.07115 https://arxiv.org/abs/2010.07115 Article: Performance Analysis for Arm vs. x86 CPUs in the Cloud, published on infoQ.com, Jan 2021. https://www.infoq.com/articles/arm-vs-x86-cloud-performance/ https://www.infoq.com/articles/arm-vs-x86-cloud-performance/ Source code of test cases: https://github.com/second-state/wasm32-wasi-benchmark https://github.com/second-state/wasm32-wasi-benchmark See if these helps. (Kinda old so will be needing more updated ones)