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

101–110 of 111 posts

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

#101

Post by carlopi »

jhgb wrote: post #59

> We have named this optimization 'PartialExecuter', the key idea behind it being taking advantage of known function parameters to find inner code blocks that cannot ever be possibly executed. I'm wondering, what exactly are the differences of this approach from "classical" partial evaluation? This seems to be a special case of it, unless I missed something.

I am not completely sure of what "classical" partial evaluation is, but probably yes, this is somehow a special case of it. I have now quite some material to read (see other links about partial evaluation or super-compilation).

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

#103

Post by kateinoigakukun »

andrewbarba wrote: post #3

Is this something that could be exposed as a generic CLI tool to replace something like wasm-opt from Binaryen?

Binaryen implemented partial evaluation at the beginning of this year https://github.com/WebAssembly/binaryen/pull/4438

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

#105

Post by hackcasual »

carlopi wrote: post #99
hackcasual wrote: post #74

How does this differ from existing LLVM interprocedural optimizations? Particularly value propagation sounds like it would handle a lot of these cases. > You might have heard of dead-code elimination, an LLVM optimization pass that removes code proven as unreachable. I was actually interested in less-obvious situations. In particular blocks that are reachable on the control flow graph, but not when consider wider exe…

Take this other example: https://gcc.godbolt.org/z/nebP68Tx8 Here by playing HumanCompiler it should be possible to prove that the if condition never evaluates to true, so removing the if is safe. This is an example of optimization that PartialExecuter is able to do. Note that some combinations of other optimizations might also be potentially able to get to this result (say adding a tag "is always power of 2", but do…

Interesting, looks like this is bit arithmetic related, as it looks like even complex expressions seems to be handled fine, as long as there's no bit ops.

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

#106

Post by johncolanduoni »

pjmlp wrote: post #93
johncolanduoni wrote: post #90

Earlier quoted context omitted.

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.

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

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.

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

#107

Post by MaxBarraclough »

pjmlp wrote: post #94
sfink wrote: post #52

Earlier quoted context omitted.

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

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.

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.

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

#108

Post by MaxBarraclough »

sfink wrote: post #52
pjmlp wrote: post #40

Earlier quoted context omitted.

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.

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

> 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?

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

#109

Post by carlopi »

astrange wrote: post #87
saagarjha wrote: post #77

Earlier quoted context omitted.

My understanding is that CheerpX, but simulating a full userspace, can optimize all the way through system libraries, which are typically very general and have lots of code that is “dead” to your application. How would this approach fail for applications where the code tends to be more specific to the task?

Seeing through system libraries sounds problematic already, since some of them like libc violate aliasing when you can see their implementations, even in LLVM byte code form.

I have to double check this, but the approach should be theoretically sound since we are quite strict with what functions are considered to have known call-sites: Function has to be internal (as in no visibility from outside) + no indirect uses (so no saving a pointer to the function somewhere). This should be enough to solve the problem you are thinking about.

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

#110

Post by sfink »

MaxBarraclough wrote: post #108
sfink wrote: post #52

Earlier quoted context omitted.

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

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

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

Post reply on HN