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

PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

leaningtech.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#61

Post by jchw »

unnouinceput wrote: post #21
gavinray wrote: post #9

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

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.

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.)

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#62

Post by carlopi »

densh wrote: post #53

Thanks for sharing, we ended up designing something very similar in Scala Native [1]. The use case we had was to explore all possible code paths was to reduce the overhead of virtual call dispatch (since very often virtual calls have very few targets in practice), which is extremely dominant and prohibitive in JVM languages unless optimized away. I hope to see your work upstream in LLVM. [1]: https://scala-native.rea…

Devirtualization is always plenty of fun + has lots of potential. Added to the list of article to read.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#63

Post by mhh__ »

api wrote: post #24

Please mainstream this in general. It would save a decent amount of RAM if it became a standard part of LLVM and would probably improve overall performance due to cache effects. Dead code sitting in RAM would be bad for cache locality.

It could save ram but presumably if applied wrong you could waste ram by having multiple copies of the code. So you'd probably want to profile guide this.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#64

Post by mhh__ »

eklitzke wrote: post #48
fsiefken wrote: post #32

Earlier quoted context omitted.

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".

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.

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.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#65

Post by nix0n »

the_duke wrote: post #43
pjmlp wrote: post #26

Earlier quoted context omitted.

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

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…

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

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#66

Post by api »

mhh__ wrote: post #63
api wrote: post #24

Please mainstream this in general. It would save a decent amount of RAM if it became a standard part of LLVM and would probably improve overall performance due to cache effects. Dead code sitting in RAM would be bad for cache locality.

It could save ram but presumably if applied wrong you could waste ram by having multiple copies of the code. So you'd probably want to profile guide this.

Dead code removal and deduplication are orthogonal aren't they? You can already turn off verbosity increasing things with -Os etc.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#67

Post by the_duke »

nix0n wrote: post #65
the_duke wrote: post #43

Earlier quoted context omitted.

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…

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

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.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#68

Post by JoshTriplett »

carlopi wrote: post #22
JoshTriplett wrote: post #5

This looks great! Please consider upstreaming this into LLVM; it would benefit many other users of LLVM. I'd love to see this used in Rust, for instance. What kind of compilation performance do you see for how long this pass takes? Do you apply this to all functions, or to all functions with certain properties, or to functions tagged some particular way?

Thanks a lot! I also believe it would be cool to upstream this, we will have to sit down and do some planning. Compilation time could improve (I was actually working on this today), but it's already in line with other optimizations, taking Currently it's applied to all functions, since runtime it's anyhow somehow linear in the number of Instructions a Function has, but possibly in more costly versions of this (that w…

When upstreaming it, it might make sense to give it two mechanisms: either process every function, or process only functions labeled to use it. Then, a frontend can experiment with things like automatically detecting which functions would benefit from it, using language-specific mechanisms. Or, worst-case, frontends can provide attributes to tag functions explicitly, and libraries can tag functions known to benefit from this.

Re: PartialExecuter: Reducing WebAssembly size by exploring all executions in LLVM

#70

Post by deathanatos »

mhh__ wrote: post #64
eklitzke wrote: post #48

Earlier quoted context omitted.

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.

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.

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…)
Post reply on HN