HN Theater @HNTheaterMonth

This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser.

Also a JVM to WASM transpiler.

There's a fantastic Meetup presentation given by one of them where they show running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill. Really mindblowing:

https://youtu.be/7JUs4c99-mo?t=167

⬐ mysterydip

> running a C++ multiplayer game with both client AND server running in a browser, using WebRTC as a networking polyfill

Ok, now you have my attention. Been waiting for that possibility for a while!

⬐ yuri91

If you are interested, here is the article I wrote about that particular project: https://medium.com/leaningtech/porting-a-c-multiplayer-game-...

⬐ fsiefken

What would the impact be on battery life compared to native execution? Can one get it just as power efficient as native execution, only slower? For computationally less intensive applications browser portability might be an excellent tradeoff.

It gives a new meaning to the slogan "write once, run everywhere".

⬐ fulafel

Users of computationally intensive applications aren't such efficiency freaks much of the time, they tend to take "good enough" in that dpartment, like it is in other areas. In addition to cross platform portability they appreciate outcomes that stem from development performance/productivity (timely app delivery, app correctness and robustness, low cost, features, adaptability to feature requests, usabiity, etc).

⬐ eklitzke

Generally things that run faster are more power efficient, because the CPU has to run for less time to do the same work. There might be a few odd exceptions here and there, e.g. certain AVX instructions can use a lot of power, but they're not common.

⬐ mhh__

Those AVX instructions use more power at least in part because they massively better utilize the silicon, so you're making a tradeoff between speed and efficiency as per usual.

⬐ deathanatos

Sorry, but to be pedantic for a second: do they consume more energy, which is really what I care about for battery life? (Let's assume I'm committed to asking the machine to do whatever work it is that I asked it to do, so the required computation is constant, for discussion.) My understanding of AVX is that it consumes more power, yes — but the point the parent makes is a good one: if it finishes faster, where does the energy use come out? More power over less time can mean less energy. (Or more. Depends on the additional power vs. the time saved…)

⬐ mhh__

1. This all depends massively on the actual workload and chip, a lot of people are basically winging it when it comes to AVX power consumption stories. The rub is also that, especially on laptops, you can get convexity in all the scaling problems e.g. you do more work, good, but then the laptop throttles then stays throttled for a while etc.

2. The original (real) power issues with the original/early AVX-512 desktop chips have basically gone away. It's not far off the timescale that you'd looking back to be bashing AMD for bulldozer.

I'd measure it for you on my machine but I don't have an accurate power-o-meter for my computer.

⬐ astrange

I've seen several student projects that try to find "more energy efficient" compilations through random searches of compiler flags etc., but they never get any results.

In a JIT language you might be able to save time by running the JIT less often though.

⬐ MaxBarraclough

Have any of these attempts taken a profile-guided approach?

⬐ zeusk

At what point does the browser become an "os", what's next? Chrome hypervisor?

⬐ runeks

> At what point does the browser become an "os", what's next?

When it no longer requires an OS to run.

⬐ enos_feedler

So ChromeOS

⬐ runeks

ChromeOS is Linux

⬐ dmitrygr

It happened about a decade ago.

⬐ tentacleuno

Not sure what you mean by hypervisor, but Microsoft does have... Microsoft Defender Application Guard, I believe it's called. It's a totally sandboxed version of Edge.

⬐ sva_

I'd be much more willing to execute some binary in my browser than directly on my OS. Sure, you could do a VM or so, but a browser tab is spun up much more quickly.

The absence of friction of just executing something quickly, and being able to share it with a single text string, is what makes this appealing to people, I reckon. I dunno why people seemingly get offended by this.

⬐ unnouinceput

This sounds like ActiveX. Security issues related to ActiveX are solved or not? Because if they are not, then it's just a reskin of ActiveX and malware authors gonna have a field day.

⬐ apignotti

There is a very big difference: ActiveX was native code that was literally running on your system with full access to system calls.

CheerpX is a Virtual Machine environment, it JIT compiles Wasm code from x86 binaries and it is fully sandboxed by the browser. It _cannot_ access your system even if it tried.

⬐ pjmlp

It can still be exploited the Applets/Flash way, by forcing the internal memory to become corrupted and with it change its behaviour.

⬐ MikeHolman

Wasm has the same security risk as executing JavaScript in your browser, except with less risk of XSS type security issues because wasm modules are better encapsulated.

⬐ nynx

It literally cannot.

⬐ pjmlp

I advise some courses in pentesting.

⬐ codr7

Assuming the VM can't be exploited/escaped somehow, which would be a first.

⬐ sfink

Right, you can corrupt memory and thereby alter behavior, but that memory is a managed array. You can't corrupt anything outside of the application's own memory. As you say, you can change behavior, and thereby do whatever you want with whatever the wasm application is allowed to access. Which is a very limited set of things.

Likening it to Java applets or Flash is deceptive -- yes, you can still hack them and exploit vulnerabilities. But the scope of what you can do with such vulnerabilities is wildly, dramatically different. Even when sandboxed, Flash has an enormously wider attack surface to play with. WebAssembly has barely anything.

It's like the difference between patching a leak in your roof with a sponge vs tar paper. In theory, water could find a path through the tar paper.

⬐ pjmlp

Imagine a WASM module used to control security authentication in the browser, or controlling IoT devices in a factory, now that it is fashionable to run WASM outside of the browser.

⬐ johncolanduoni

You could also imagine a native executable doing the same, which in most cases won’t even have the level of control flow integrity protection WASM will have. I’m not clear what superior alternative you’re comparing with.

⬐ pjmlp

Currently WASM has less security protections than native sandboxes, not more. Read security section of the standard.

⬐ johncolanduoni

It has less mitigation than the Chrome or the Linux kernel. It has much better CFI than the vast majority of actual C++ userspace applications.

⬐ sfink

Right, I agree that wasm being used to control nuclear launches is not fundamentally better than native sandboxed C++ code in terms of preventing unwanted nuclear launches.

But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light.

I'm guessing we don't actually disagree on anything here -- I also feel like people are making unwarranted assumptions that wasm gives you more safety than it actually does. (It reminds me of another incorrect assumption that seems to get made a lot, that running unsafe code in a VM means you don't need to worry that it'll escape to the host or other VMs on that host.)

⬐ pjmlp

Yes, it is those unwarranted assumptions that irk me, as then you see talks how everything is "magical" with WASM, when it is just yet another bytecode format.

⬐ MaxBarraclough

Right, the only 'magical' thing about WASM is that it has browser support. On the plus side, browsers have a comparatively good track-record as secure sandboxes. Far better than the JVM, say.

⬐ MaxBarraclough

> But wasm being used to control the brightness pattern of a blinky light on the console of the machine that controls nuclear launches? That is fundamentally safer than native sandboxed C++ code being used to control the blinky light.

How so? There are established techniques for developing safety-critical software, and they don't tend to rely on the assumption that a sophisticated JIT compiler is free of bugs.

Or do you mean untrusted code for controlling the blinky light?

⬐ sfink

If you're following the proper techniques for safety-critical software, then none of this matters; it makes no difference whether you're using wasm or straight C++.

So yes, untrusted code, but "untrusted" is ambiguous. There's Web-style untrusted code, where the code could be malicious. Then there's unverified code, where the author is presumed to have good intentions but you can't trust the correctness. WebAssembly is useful for both as long as your outputs are properly constrained (as in, it's the blinky light case, not the nuclear launch case.)

The distinctions aren't even 100%. Perhaps your adversary, shortly before launching their nukes, triggers the malware in your blinky light controller to blink at the exact frequency that you know will send the operator into a seizure, preventing them from triggering the counter-launch. You know, because you surreptitiously tested all the people a decade ago when they were applying for the nuclear launch controlling position, and did character assassination on all those who were not susceptible to blinky light seizures... ;-)

⬐ MaxBarraclough

> If you're following the proper techniques for safety-critical software, then none of this matters; it makes no difference whether you're using wasm or straight C++.

Under what circumstances would it be appropriate to use WASM in a safety-critical system?

To my knowledge there's no WASM implementation intended or approved for use in safety-critical systems.

> WebAssembly is useful for both

I don't think so. I can't see a reason to let lives hang in the balance of a WASM implementation being free of bugs. Use an approved C/C++/Ada compiler and be done with it.

You're right that WASM is pretty robust against malicious code that aims to escape the sandbox. Sames goes for JavaScript. Web browsers are of course very motivated to focus on the security of their language engines.

> Perhaps your adversary, shortly before launching their nukes, triggers the malware in your blinky light controller to blink at the exact frequency that you know will send the operator into a seizure

I don't see WASM having a place in the development of ultra-low-defect software. If you're serious about that kind of thing you use a language and framework like SPARK Ada.

I agree though that WASM may be useful in mitigating the consequences of undefined behaviour in buggy C/C++ code, in some circumstances. In this regard it's nothing new. C/C++ can be compiled to just about anything, including other sandbox-oriented languages like JavaScript. WASM just improves the performance. Linux has been 'ported' to JavaScript at least twice. [0][1]

[0] https://bellard.org/jslinux/tech.html

[1] https://medium.com/@retrage/lkl-js-running-linux-kernel-on-j...

⬐ runeks

> It _cannot_ access your system even if it tried.

That’s the intent, at least. I’m sure we’ll get to see exploits that manage to do exactly this.

⬐ comex

Perhaps, but if so, that would be a bug in the browser’s WebAssembly implementation, not CheerpX.

⬐ jfoutz

CheerpX looks amazing. Not blaming that project it in any way.

But rowhammer is still a thing.

There's a whole stack of abstractions, that all _may be_ vulnerable. I'm sure CheerpX is very good, but there's no way to _know_ that all the dependencies from the toolchain used to build all the way down to the running environment is actually bug free.

As a first line of investigation, I'd suspect cheerpX, just because so many eyes look at browser sandboxes. _shrug_ your milage may vary.

⬐ saagarjha

You can Rowhammer from JavaScript already, so this really has nothing to do with CheerpX.

⬐ jfoutz

Very true. Let me try to restate.

I don't know how to prove the absence of a thing. I can only prove existence.

I was trying to highlight that every layer of abstraction has vulnerabilities all the way down to the hardware level.

I'm perfectly willing to accept that CheerpX has no known vulnerabilities.

⬐ jerry1979

It may have more to do with the idea that since CheerpX runs in the browser, the threat model of CheerpX is the same as the thread model of using your web browser to browse any other site.

⬐ pjmlp

That is the thing with fake security advertising of WebAssembly.

You can just as easily compile heartbleed into WebAssembly and call it a day.

Yes it is sandboxed, but hardly any different than running an OS process with sandboxing lock down regarding which OS syscalls are allowed.

Think it this way, just because an OS container cannot exploit its host (minus hypervisor bugs), that doesn't mean that what is inside isn't subject to security flaws.

⬐ detaro

So, a lot better than ActiveX, which didn't have effective sandboxing and all the problems webassembly still has due to (lack of) memory protection etc.

⬐ the_duke

You keep repeating this, but it's simply not true.

The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access to pre-opened sockets.

All production deployments of server side Wasm I have seen have very tight scoping.

Sandboxing on Linux, in contrast, is a complicated mess, with a myriad of partial and leaky solutions (SELinux, Apparmor, Docker, Snap, Flatpak, ...) .

Having a good cross platform toolkit is completely out of reach.

The only OS that has comparable sandboxing that is practical is Fuchsia.

⬐ astrange

Darwin has quite good sandboxing, although how to actually use it isn't documented.

⬐ pjmlp

And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed.

There is no magic in WASM, only when the only thing it does is warming up a CPU.

⬐ the_duke

I'm happy to have a technical discussion, but your comments always stop at "Wasm bad", without countering the arguments.

⬐ pjmlp

It is not worth having a technical discussion with WASM advocates, because their comments always happen with "it doesn't happen in WebAssembly, we are the most secure format of the world", even though security researchers are already slowly looking into it.

So I will asserting the obvious that anyone that cares about actual security is aware of, and keeping a champagne bottle on the fridge for the first collection of CVE related to WebAssembly deployments.

⬐ kaba0

I would be interested in the previously mentioned claims like “wasm can’t protect against rowhammer” —- while perhaps not an easily exploited vulnerability, and likely every current sandbox tech is vulnerable, is there anything specific to wasm that would help here?

Also, how does wasm relate to traditional sandboxes that “just” hijack system calls? Is there a difference?

⬐ nix0n

Is this true of server side only, or is there a practical solution for locking down JS within the browser?

⬐ the_duke

Wasm has no access to any browser APIs by default, so yes.

You can expose the required functionality via JavaScript bridges.

The current Rust (wasm-bindgen) and C/C++ (emscripten) tooling exposes the the whole browser API by default though, which isn't ideal.

⬐ jchw

HN is doing its typical “well, technically,” thing in the replies here, so I’ll give a better answer: Yes, the problems that plagued ActiveX are gone now. WebAssembly hosts still have vulnerabilities from time to time, but they are not literally by-design like they were with ActiveX. They’re typically complicated and to do similar things to what ActiveX modules could do completely ordinarily would require breaking many sandbox layers.

The discussion also is breaking into an unrelated branch about security within WebAssembly, so it’s worth pointing out that the security model of WebAssembly is that it should prevent the host machine from being attacked by code running in the sandbox, not that it makes code running in the sandbox any more secure. It doesn’t make code in the sandbox not susceptible to most classes of errors, it just isolates those errors to runtime errors and not exploitable bugs that can escalate privilege.

ActiveX, of course, did not deal with either security model, instead shrugging it off and just assuming that code signing would be a good enough deterrent to malware.

(Of course, the problem with this is manyfold, including the fact that just because a module is trustworthy and not malicious, does not mean it should be exposed to all users, and the fact that even if you trust the company behind the module, that doesn’t make the module any more guaranteed to be secure.)

⬐ apignotti

> This company has an x86-to-WASM compiler that lets you execute arbitrary binaries in the browser.

Direct link to our latest demo in case anybody would like to see this tech in action: https://webvm.io

It's been on our minds for a while, the major issues with this is that IPC between the app process and WebKit is like 100µs, so having the interpreter run isolated from the app process is hard. Plus loading WASM is not "free" (that is, essentially an instruction cache flush) because you need to generate a bundle that WebKit will then load, which is slow (although there has been work done in this area: https://www.youtube.com/watch?v=7JUs4c99-mo). So even if we did some sort of WASI thing where everything is going on in the browser, there are hurdles to overcome to make this viable. Plus the current interpreter almost certainly leaves performance on the table ;)

⬐ tambourine_man

It’s so cool that you have actually considered it.

Imagine what developers could do if Apple loosened those restrictions a bit.

Technical details in this WebAssembly SF video: https://youtu.be/7JUs4c99-mo?t=24

At Leaning Technologies, we are working on preserving _all_ flash content by running the original x86 Flash plugin via WebAssembly virtualization (CheerpX). If you want to read more:

https://medium.com/leaningtech/running-flash-in-webassembly-...

https://medium.com/leaningtech/preserving-flash-content-with...

A presentation about the architecture of the system: https://www.youtube.com/watch?v=7JUs4c99-mo

Feel free to drop me any question: https://twitter.com/alexpignotti

⬐ apignotti

Forgot to mention, if you want to see our virtualization tech in action: https://repl.leaningtech.com/python3.html

⬐ lopis

Amazing work! Years ago Mozilla was working on a javascript implementation to help support legacy flash content on a Flashless web, but that got quickly abandoned before it mature significantly. Glad that someone else is working on it with a more modern approach.

⬐ apignotti

You are referring to Shumway. I was working at the time on Lightspark, another FOSS implementation. All these efforts, including the recent ones, like Ruffle, are doomed due to the sheer complexity of implementing Flash from scratch.

Our approach is different. We run the binary plugin safely in the browser via WebAssembly virtualization.

Here's a talk by the team as well: https://www.youtube.com/watch?v=7JUs4c99-mo

And their website: https://www.leaningtech.com/pages/cheerpx.html

This is honestly one of the coolest things I've seen, and given the amount of Flex/Spark software for enterprise out there, it could drastically change the legacy software landscape.

⬐ txdv

It really sounds awesome, but I can't just download it and play with it.

I hope they release something usable that I can just download and play around with. I'm not a huge company which will create something really amazing and can pay royalties to them, I guess I am not interesting