Wasmer 3.0 Released As The Latest "Universal WebAssembly Runtime"

[phoronix]

Phoronix: Wasmer 3.0 Released As The Latest "Universal WebAssembly Runtime"

Following the development builds over the summer, Wasmer 3.0 was officially released this weekend as the newest feature release for this open-source software aiming to serve as a universal WebAssembly runtime with a goal to "run any code on any client" via WebAssembly...

https://www.phoronix.com/news/Wasmer-3.0-Released

[linuxgeex]

Projects like Box64 and FEX are the future of cross-platform. DEC Alpha used thunking and recompilation to run 32-bit x86 Windows apps at near-native speed. It took a while for that tech to trickle down, but now it's here.

DaoOS using a bytecode and JIT before Java. Java made the tech popular. WASM is just another wave of bytecode/JIT.

WASM proponents would have you believe that WASM is on a track for native performance. It will never happen. The problem with bytecode/JIT is that it's self-modifying code, which has unsolvable security problems. That will always make it slow. Increasingly slower with time thanks to increasing security mitigations around increasing CPU ROB depth, which is required for increased IPC.

So this is not the Panacea they're selling us. The real Panacea is standardised APIS & ABIs + AOT Binary Translation + Thunking.

[gosh000]

Actually current implementation of WASM (WebAssembly) has no JIT, even WASM has no garbage collector.

[NobodyXu]

The problem with bytecode/JIT is that it's self-modifying code, which has unsolvable security problems.

Self-modifying code?
What are you talking about?

JIT simply takes codegen plus some optimization passes into the program runtime.
Also it doesn't have unsolvable security problem, the program simply allocates a read-write only mmap first and then writes the generated native binary code to it,
then changes the permission from read + write to executable + read only.

JVM is used in enterprise all the time so I absolutely have no idea what you are saying.

So this is not the Panacea they're selling us.

This is not for the end-users, but for deploying software at mass in companies/governments.
It's already used in clouds.

[QUOTE=linuxgeex;n1358343]
The real Panacea is standardised APIS & ABIs + AOT Binary Translation + Thunking.

Well, wasm also supports sandboxing, which also makes it a replacement for docker in some scienarios.

[linuxgeex]

Also it doesn't have unsolvable security problem, the program simply allocates a read-write only mmap first and then writes the generated native binary code to it,
then changes the permission from read + write to executable + read only.

And that requires TLB flushes, which is part of why it's slow. WASM is worse because it's more fine-grained and supports dynamic types, so the pages are more fragmented, requiring more page walks and more flushes.

JVM is used in enterprise all the time so I absolutely have no idea what you are saying.

In the 2000's there was apocryphal belief among CEOs that Java was secure by design. There's nothing inherently safe about JVMs. Just because it's used in Enterprise doesn't make it safe. In Enterprise security is almost always hamstrung by compatibility needs, and/or incompetent policy makers relying on narcissistic middle management who would rather throw the company under the bus to make themselves seem important rather than grease the wheels and let frustrated competent security professionals do their jobs. Choice of language in Enterprise has nothing to do with security. If it did, they would use Rust. The vast majority of exploits are implemented in C and Python, but that doesn't stop Enterprise from using C and Python for speed and convenience.

Well, wasm also supports sandboxing, which also makes it a replacement for docker in some scienarios.

Elizabeth Holmes may as well be at the helm promoting WASM. Yes in theory that sandbox is safe in spec. But what about in implementation? The reality is that vulnerabilities are being found regularly still. Like any young project its security will mature with age, but its performance will suffer with mitigations, which was my point... if we want high performance cross-platform binaries there's far more mature (well researched if not decades in implementation) tech to make that work, and I would much rather rely on hardware-enforced security (ie AMD-SEV) than a wishful-thinking software sandbox.

Sadly, the CEOs will continue to be swayed by golf course gossip instead of listening to their engineers, and making risk-averse decisions to keep insecure, unpatched, unsafe-by-design platforms so they can keep running software that they feel they can't dare replace, because the people who wrote the software have retired lol.

[NobodyXu]

And that requires TLB flushes, which is part of why it's slow. WASM is worse because it's more fine-grained and supports dynamic types, so the pages are more fragmented, requiring more page walks and more flushes.

I'm not familiar with the details design, but AFAIK there have been attempts to speed it up.
There's wizer https://github.com/bytecodealliance/wizer which pre-initializes the program and gives a huge speedup.

Also, I think wasmer actually does not support JVM-like JIT where each function is compiled to native when needed, but the entire image is compiled down the native code at once.
You can also use wasmer create-exe to convert wasm to native elf that can be run directly on the platform.

wasmer supports three compilers: llvm, the one gives the best performance but takes some time to compile.
cranelift, much faster but generates slower code.
singlepass, emit compiled code at linear time and not prone to JIT bombs, but slower than cranelift.

In the 2000's there was apocryphal belief among CEOs that Java was secure by design. There's nothing inherently safe about JVMs. Just because it's used in Enterprise doesn't make it safe. In Enterprise security is almost always hamstrung by compatibility needs, and/or incompetent policy makers relying on narcissistic middle management who would rather throw the company under the bus to make themselves seem important rather than grease the wheels and let frustrated competent security professionals do their jobs. Choice of language in Enterprise has nothing to do with security. If it did, they would use Rust. The vast majority of exploits are implemented in C and Python, but that doesn't stop Enterprise from using C and Python for speed and convenience.

The link you gave mainly talks about programming error, which has nothing to do with JVM or JIT.
There isn't anything that inherently makes JIT unsafe.

BTW, wasmer is written entirely in rust.

Elizabeth Holmes may as well be at the helm promoting WASM. Yes in theory that sandbox is safe in spec. But what about in implementation? The reality is that vulnerabilities are being found regularly still. Like any young project its security will mature with age, but its performance will suffer with mitigations, which was my point... if we want high performance cross-platform binaries there's far more mature (well researched if not decades in implementation) tech to make that work, and I would much rather rely on hardware-enforced security (ie AMD-SEV) than a wishful-thinking software sandbox.

Wasm sandbox is not wishful-thinking software sandbox.

It is a capability based sandbox, where each capability has to be explicitly passed to the program for it to use.
For example, in order for the wasm program to connect to the internet, a capability must be explicitly pass.
For it to listen on ports, another capability is needed.
Same for filesystem operations and other I/Os.

Each wasmer program also operates in separate memory regions, a memory bug in one would not affect other programs and would likely trigger that program to exit.

It also has built-in migration against ROP and it uses clang CFI according to https://webassembly.org/docs/security/

[linuxgeex]

The link you gave mainly talks about programming error, which has nothing to do with JVM or JIT.
There isn't anything that inherently makes JIT unsafe.

It details a JVM buffer overflow to begin with, then talks about best practices. But this is only one presentation. Simply google US-CERT JRE and you'll get thousands. Oracle publishes their vulnerabilities semi-annually. Typically there's 3-6 JRE vulnerabilities in JAVA SE affecting a broad cross-section of releases from 8 - 17. I'm not talking about components like Log4j. I'm talking about Java SE Core like Hotspot.

BTW, wasmer is written entirely in rust.

Jargon/marketing. Rust primarily avoids buffer overflows and use-after-free. Those are important, but Rust is still far from a magic bullet against human error.

Wasm sandbox is not wishful-thinking software sandbox.

It is a capability based sandbox...

As I said: in spec, it's safe. But in implementation it is not. I provided links to 2 vulnerabilities disclosed October 2022. There's more.

I wish you'd say something bad about wasmer that's wrong so I get an opportunity to say something nice about it, so I don't have to come across like a hater. I don't hate it. I just think there's better tech available which doesn't reinvent the wheel, fragment the market, and guarantee worse performance in the future. I think wasm is good for what it was designed for - as a way to provide near-native performance for compute-intensive parts of web apps. I think web tech as an app platform in general though is a very bad idea... and this is coming from someone who makes their living delivering web apps.

[NobodyXu]

It details a JVM buffer overflow to begin with, then talks about best practices. But this is only one presentation. Simply google US-CERT JRE and you'll get thousands. Oracle publishes their vulnerabilities semi-annually. Typically there's 3-6 JRE vulnerabilities in JAVA SE affecting a broad cross-section of releases from 8 - 17. I'm not talking about components like Log4j. I'm talking about Java SE Core like Hotspot.

Well I did the google and find quite some CVE reports.
It certainly isn't 100% safe, but what I was trying to say is that JIT itself isn't inherently unsafe or terrible as long as it is properly implemented.

While for some use cases, compiled language is indeed better as you can even disable mmap executable code altogether to avoid some potential bugs, I think it is mostly OK to use.

Jargon/marketing. Rust primarily avoids buffer overflows and use-after-free. Those are important, but Rust is still far from a magic bullet against human error.

It certainly isn't and there is still some code required to be written using unsafe, though these unsafe lines are quite small compares to other safe code and easy to audit.
That is to say, I still think this is an advantage.

Wasmer needs to parse the wasm bitcode, load it plus the compiler like cranelift and singlepass, which is also very complex.
These tasks are typically error prune and there are often out-of-bound bugs in the parser (I heard libexpat also have a CVE which firefox migrates by running it inside wasm, which won't be there if it is just rewritten into Rust) and same for the compiler.

P.S. There's ongoing effort to use the cranelift codegen in rustc to speedup debug build.
I am looking forward to this, in additional to the rustc_codegen_gcc backend.

As I said: in spec, it's safe. But in implementation it is not. I provided links to 2 vulnerabilities disclosed October 2022. There's more.

There will no doubt be CVEs in there, though it is from https://github.com/WebAssembly/wabt which is written in C++.

IMO wasm is still quite an interesting technology.
With "wasmer create-exe", it is possible to distribute binaries by wasi (which is still ungoing standardisation, a shame that makes it less useful) and use wasmer create-exe to generate native executable, compile once and run everywhere with near native performance and near native memory usage compared to JVM.

That's going to speed up development time as it no longer needs to run the CI for every target to be supported and add workarounds for them, plus release and distribute is also going to be way easier.

I am one of the maintainers of cargo-binstall, which has to run cargo or use syscall to detect target, add fallback like x86_64-unknown-linux-musl, x86_64-apple-darwin and newly added, not standardised universal-apple-darwin, and then trying to discover the archives on their repository if the link is not explicitly specified.

With wasmer, it's easier as one wasm file can be run everywhere and they even have a dedicated platform to upload and download the wasm files.

I'm not to say cargo-binstall is useless as native still performs better, and sometimes they might link to local dynlibs, and there's now lots of thing wasi cannot do, and probably there are situation where wasm may not be trusted by someone, but having wasm as a fallback really sounds interesting to me.

I wish you'd say something bad about wasmer that's wrong so I get an opportunity to say something nice about it, so I don't have to come across like a hater. I don't hate it. I just think there's better tech available which doesn't reinvent the wheel, fragment the market, and guarantee worse performance in the future. I think wasm is good for what it was designed for - as a way to provide near-native performance for compute-intensive parts of web apps. I think web tech as an app platform in general though is a very bad idea... and this is coming from someone who makes their living delivering web apps.

It's definitely good for web, and maybe for serverless or whatever it is called.
I think it will be interesting to use wasm in distributed computing where traditionally JVM is used, since compiling C/C++/Rust to wasm is way easier and wasm can be used to compile them down to native executable before running.

Though with Graalvm from Oracle, it is also possible to compile C/C++/Rust to run on JVM and maybe mix with Java (IDK if can it optimize them together though) but having some competition here is good because it's Oracle and they already starts charging for enterprise Graalvm which has some more features.
If they have a monopoly, maybe they would even close source it.

When I commented on wasm, I didn't think about app platform.
It might be a reasonable expend of usage in web app and I've seen people trying to do that.
With the current state of WASI, there's definitely a lot lacking, like standardised networking, async, etc and I'm not sure how efficiently wasm can run GUI.
Though its memory usage is probably going to be less than electron, that memory hog.

[linuxgeex]

With the current state of WASI, there's definitely a lot lacking, like standardised networking, async, etc and I'm not sure how efficiently wasm can run GUI.
Though its memory usage is probably going to be less than electron, that memory hog.

So far I haven't seen FFI for a wasm -> binary compiler... instead they seem to like slurping the kitchen sink. With popularity will come FFI and then language bindings for many popular libraries... with Node we've been there for some time. There's also QT Creator's new wasm target. So actually, GUI is in good shape. It's very easy to be better than Electron. It's basically impossible to deliver a Hello World Electron app that can run in under 200MB RAM and 70MB compressed binary, and those numbers just keep getting larger.

To be fair, even native cross-platform package systems like Snap, Flatpak etc also slurp the kitchen sink, use even more silly amounts of disk and RAM, and feature unspeakable startup times due to compressing the slurped kitchen sink. Using Box86 you can start up x86 Windows Zoom client faster on a Raspberry Pi under Linux ARM than you can a native x86 Linux Zoom client on a Threadripper under Linux with Snap... sigh.

[NobodyXu]

So actually, GUI is in good shape.

That's good to hear.

It's very easy to be better than Electron. It's basically impossible to deliver a Hello World Electron app that can run in under 200MB RAM and 70MB compressed binary, and those numbers just keep getting larger.

Well, that's why I don't like these "modern Apps" and why I don't use code editor like vs code or atom but instead neovim.
Their memory usage is way too much.

To be fair, even native cross-platform package systems like Snap, Flatpak etc also slurp the kitchen sink, use even more silly amounts of disk and RAM, and feature unspeakable startup times due to compressing the slurped kitchen sink. Using Box86 you can start up x86 Windows Zoom client faster on a Raspberry Pi under Linux ARM than you can a native x86 Linux Zoom client on a Threadripper under Linux with Snap... sigh.

Not familiar with snapd/flatpak since I am currently using MacOS.