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

Wasm3 – A high performance WebAssembly interpreter in C

github.com

Post reply on HN
Print view View original

21–30 of 79 posts

Re: Wasm3 – A high performance WebAssembly interpreter in C

#21

Post by pjmlp »

ridiculous_fish wrote: post #19
tasogare wrote: post #17

Earlier quoted context omitted.

How is that different from CLR or JVM?

I'll speak to JVM; I'm less familiar with CLR but I believe it's the same. JVM and WASM both have statically-verifiable control flow. No wild jumps, no executable stacks, etc. Phew. Arrays and pointer arithmetic are a big difference. WASM has a big linear memory block, and instructions may access arbitrary locations within it - the runtime performs bounds checking only at the edges. So your `sprintf` can still overfl…

CLR was designed to support C++ since day one.

And while WASM trumps the security trumpet, without actually supporting proper bounds checking, the CLR will taint C++ pointer arithmetic as unsafe, thus making the whole module unsafe.

So I as consumer can decide if I am willing to trust an unsafe module or not.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#22

Post by vijaybritto »

CharlesW wrote: post #4

Why is an interpreter desirable when JIT compilers create significantly faster code? Is this primarily about embedded use?

From what I know, its because JIT uses a lot more memory than an interpreter. Also in LUAJIT it uses very little memory and thats why people have their minds blown all the time.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#23

Post by cfallin »

pjmlp wrote: post #20
ridiculous_fish wrote: post #16

Earlier quoted context omitted.

WASM has a sandboxing model. The idea is: 1. Control flow is always checked. You can't jump to an arbitrary address, you jump to index N in a control flow table. 2. Calls out of the sandbox are also table based. 3. Indexed accesses are bounds checked. On 64 bit platforms, this is achieved by demoting the wasm to 32 bit and using big guard pages. On 32 bit platforms, it's explicit compares. The result is something whi…

Internally inconsistency is already good enough for possible security exploits, by making the module reveal stuff that would otherwise be forbidden.

That's not the goal of a VM/runtime, though: it only ensures that the hosted code cannot escape the sandbox, and provides a correct implementation of the semantics of each VM opcode. The hosted code's computation implemented with those opcodes is a black box to the VM.

Consider: should the VM somehow try to analyze the running code and determine when it's about to commit a logical error and return "forbidden" data? What specification states which data is forbidden?

Consider: even the most high-level VM can execute a program with logical errors if it is Turing-complete. A Java or Erlang program running on a bug-free, fully-compliant implementation of the respective VM can still get (e.g.) an authorization condition wrong, or incorrectly implement a security protocol, or return data from the wrong (in-bounds, but wrong!) index in an array.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#24

Post by johncolanduoni »

pjmlp wrote: post #21
ridiculous_fish wrote: post #19

Earlier quoted context omitted.

I'll speak to JVM; I'm less familiar with CLR but I believe it's the same. JVM and WASM both have statically-verifiable control flow. No wild jumps, no executable stacks, etc. Phew. Arrays and pointer arithmetic are a big difference. WASM has a big linear memory block, and instructions may access arbitrary locations within it - the runtime performs bounds checking only at the edges. So your `sprintf` can still overfl…

CLR was designed to support C++ since day one. And while WASM trumps the security trumpet, without actually supporting proper bounds checking, the CLR will taint C++ pointer arithmetic as unsafe, thus making the whole module unsafe. So I as consumer can decide if I am willing to trust an unsafe module or not.

The CLR doesn’t guarantee control flow integrity (modulo type confusion) or any form of isolation when linear memory accesses are used. So here WASM offers another option in the middle between trust and don’t trust: “trust unsafe module only to not compromise its own functionality; no attacking the rest of the process or kernel” (modulo runtime bugs).

Re: Wasm3 – A high performance WebAssembly interpreter in C

#25

Post by pjmlp »

cfallin wrote: post #23
pjmlp wrote: post #20

Earlier quoted context omitted.

Internally inconsistency is already good enough for possible security exploits, by making the module reveal stuff that would otherwise be forbidden.

That's not the goal of a VM/runtime, though: it only ensures that the hosted code cannot escape the sandbox, and provides a correct implementation of the semantics of each VM opcode. The hosted code's computation implemented with those opcodes is a black box to the VM. Consider: should the VM somehow try to analyze the running code and determine when it's about to commit a logical error and return "forbidden" data? W…

Indeed, what WASM advocates cannot do is advocate safety, that it is better than any other bytecode format since 1958, when it isn't so.

Secondly, it could have been designed with bounds checking for any kind of data access.

The CLR is honest about it, when C++/CLI uses C style low level tricks, the Assembly is considered tainted and requires explicit allowance of unsafe assemblies execution.

An idea that goes back to Burroughs B5000, where tainted binaries (code using unsafe code blocks) requires admin permission for execution.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#26

Post by pjmlp »

johncolanduoni wrote: post #24
pjmlp wrote: post #21

Earlier quoted context omitted.

CLR was designed to support C++ since day one. And while WASM trumps the security trumpet, without actually supporting proper bounds checking, the CLR will taint C++ pointer arithmetic as unsafe, thus making the whole module unsafe. So I as consumer can decide if I am willing to trust an unsafe module or not.

The CLR doesn’t guarantee control flow integrity (modulo type confusion) or any form of isolation when linear memory accesses are used. So here WASM offers another option in the middle between trust and don’t trust: “trust unsafe module only to not compromise its own functionality; no attacking the rest of the process or kernel” (modulo runtime bugs).

Well for that execution of unsafe Assemblies was already enabled anyway, so there isn't much that the verifier can do.

Which is something that WASM isn't being honest about, corruption of internal data structures is allowed.

If I can control what goes into memory just by calling module public functions with the right data set and access patterns, CFI won't help a thing.

Suddenly the authorization module that would authenticate me as regular user, might give me another set of capabilities and off to the races.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#27

Post by sebcat »

newnewpdro wrote: post #9
leetrout wrote: post #6

Earlier quoted context omitted.

I'm hardware ignorant... would that be a system on a chip?

I suspect they're just saying they'd rather see a CPU implementing the wasm isa, in a facetious way.

AVR32 with JEM does this to some extent for Java.

http://ww1.microchip.com/downloads/en/devicedoc/doc32000.pdf

  3.   Java Extension Module
  The AVR32 architecture can optionally support execution of Java bytecodes by including a JavaExtension Module (JEM).
  This support is included with minimal hardware overhead.
EDIT: Not by implementing the ISA verbatim, but still neat though

Re: Wasm3 – A high performance WebAssembly interpreter in C

#28

Post by my123 »

pjmlp wrote: post #26
johncolanduoni wrote: post #24

Earlier quoted context omitted.

The CLR doesn’t guarantee control flow integrity (modulo type confusion) or any form of isolation when linear memory accesses are used. So here WASM offers another option in the middle between trust and don’t trust: “trust unsafe module only to not compromise its own functionality; no attacking the rest of the process or kernel” (modulo runtime bugs).

Well for that execution of unsafe Assemblies was already enabled anyway, so there isn't much that the verifier can do. Which is something that WASM isn't being honest about, corruption of internal data structures is allowed. If I can control what goes into memory just by calling module public functions with the right data set and access patterns, CFI won't help a thing. Suddenly the authorization module that would au…

Note for C++ on the CLR that you can use /clr:safe as an MSVC compilation argument. This errors out when trying to access to random pointers at compile time.

/clr:pure uses unsafe and supports those cases though.

And yeah, WebAssembly only doing bounds checking within a single memory block and not actually offering true bounds checking is a big downgrade, and a pretty much unjustified one (+ it's rare among JITted languages...).

Re: Wasm3 – A high performance WebAssembly interpreter in C

#29

Post by w0utert »

CharlesW wrote: post #4

Why is an interpreter desirable when JIT compilers create significantly faster code? Is this primarily about embedded use?

Any JIT needs an interpreter to run code sections that are not compiled (yet), and large sections (I don't have any statistics, but I would guess a very sizable majority) of the code is 'cold' and will never get compiled at all. Compiling bytecode to machine code is a relatively expensive operation in itself so it only makes sense to do it for 'hot' sections (loops, functions that get called many times, etc).
Post reply on HN