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

21–30 of 111 posts

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

#21

Post by unnouinceput »

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.

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

#22

Post by carlopi »

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 we have on paper but yet to implement) some logic to filter functions in advance could be used.

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

#23

Post by rowanG077 »

fulafel wrote: post #19
rowanG077 wrote: post #2

Have you guys looked the literature of supercompilation? This seems to be a special case of it.

All analytical solutions to optimization problems can be seen as special cases of the brute force search I guess. But SC is impractically slow for anything except a few instructions long sequences. edit: actually I was thinking of superoptimizers, I guess it's a different concept.

Supercompilation is not brute force search.

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

#25

Post by apignotti »

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.

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.

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

#26

Post by pjmlp »

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.

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.

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

#27

Post by carlopi »

masklinn wrote: post #8
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?

> 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. Or in straight C++ for that matter. Though possibly the optimisation passes relies on specific properties of the target which don't exist for non-wasm? I didn't see anything in the writeup but that doesn't mean they don't exist.

PartialExecuter happens at the LLVM's IR level, and in theory it's fully generic. Then has been only partially tested outside the Cheerp-pipeline, so I would expect it to rely on some implicit assumptions on the kind of legalizations or lowering that are done before-hand.

Target-wise, all information is kept encoded in the IR, so that part is easier (the only strange thing that might happens is bumping some alignment to 8, but I expect every target to be able to handle the prescribed IR alignemtn)

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

#28

Post by pjmlp »

apignotti wrote: post #25
unnouinceput wrote: post #21

Earlier quoted context omitted.

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.

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.

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

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

#29

Post by landr0id »

This is sweet! This is actually a very similar approach to how I deobfuscate Python bytecode: https://github.com/landaire/unfuck/blob/bfa164b4e261deffeb37...

My code is pretty messy, but I take the same exact approach of taking known function parameters, interpreting the instructions, and removing any condition and the instructions which built its arguments if it evaluates to a constant value. Even called it partial execution as well :p

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

#30

Post by pjmlp »

carlopi wrote: post #15
turminal wrote: post #4

Are the these new techniques only applicable to WebAssembly? If so, why?

WebAssembly implies static linking (malloc / printf & all are part of the shipped module) and code size matters since it directly influence users (since there might be delays in downloading big payloads). Both factors plays a role in deciding to plan putting work in optimizations like this. There are some general gains to be had with this optimization, and probably the same ideas were already around for a while, but…

Not necessarily, shared libraries are on the WebAssembly roadmap.
Post reply on HN