Live data from Hacker News

WasmEdge

wasmedge.org

81–88 of 88 posts

Re: WasmEdge

#81
post #60

Earlier quoted context omitted.

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 t…

Got it. My concern is just fragmentation of compiler/parser tooling in order to also support wit and may introduce compatibility burden to maintain (I know wasmwat is 1:1, not sure about wit). However, I'm looking forward to compiling my toy lang to WASI once its MVP is solid.

Thanks again for the effort of the elaboration.

Re: WasmEdge

#82

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…

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

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

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/

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

[2] https://www.zdnet.com/article/microsofts-control-flow-guard-... https://clang.llvm.org/docs/ControlFlowIntegrity.html

[n] https://www.youtube.com/watch?v=q7Gv4J3FyYE https://github.com/lefticus/cpp_weekly/issues/175

Re: WasmEdge

#83
post #62

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

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 With WasmEdge there is no vendor lock-in

[deleted]

Re: WasmEdge

#84
post #62

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

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 With WasmEdge there is no vendor lock-in

[deleted]

Re: WasmEdge

#85

Earlier quoted context omitted.

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…

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, w…

Thank you for your detailed response. You've looked a lot more closely at what WasmEdge is doing than I did, and I find myself agreeing with you more and more as I read your findings. (I don't know how I got the impression that their tooling use was more thorough than it actually is, but long story short: I was wrong.)

I'm left with one difficult question, though. What should we do when trying to target environments that aren't well-served by languages like Rust? The demand is clearly there, so people will keep building new things using C and C++. What do you see as the most realistic path forward for these use cases? Push harder on platform support in Rust?

Re: WasmEdge

#87
post #62

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

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 With WasmEdge there is no vendor lock-in

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.

Post reply on HN