Fixes https://github.com/paritytech/wasm-instrument/issues/15.

Waiting on https://github.com/paritytech/parity-wasm/pull/328 to be merged to update the Cargo.toml on this PR

A possibility of the overflow while calculating cost of the block in gas-metering algorithm depends on 2 factors: the cost of each instruction defined by the caller, i.e. user of the wasm-instrument crate, and the size of the wasm module (amount of instructions). Some projects can face overflow error while injecting gas calls, because of specific for them parameters of wasm module size or cost of each instruction. I believe handling overflows while cost (gas) calculation can give more freedom to wasm-instrument users.

The suggested in the PR solution:

1. Enable overflows counter while metering blocks
2. When injecting gas calls, push several gas call instructions instead of one as it is now.

Solves #11

In addition to method used beforehand (i.e. injection of calls to an imported gas function into metering blocks), this new method now available too, which:

• Injects an exported mutable global into the module, which tracks the gas left.
• Injects the local gas function which subtracts the gas spent from the global, and drops unreachable if out of gas.

This new method should make the resulting module more efficient in terms of execution time, as invoking an imported gas host function every metering block adds an overhead. Synchronization between the global and the runtime should be implemented on the execution engine side.

The stack depth calculation for the call and call_indirect instruction here

https://github.com/paritytech/wasm-utils/blob/b22696aaa516212284f2d94a28d8d292afe27859/src/stack_height/max_height.rs#L268-L293

fails to account for the full function activation frames as described in the specification.

For that reason it is possible to write a WASM program which, when instrumented, could place frames onto the stack and overflow it regardless of the limit imposed.

Most straightforward such WASM module may look like this

(module
  (type (;0;) (func))
  (func (;0;) (type 0)
    call 0)
  (func (;1;) (type 0)
    call 0)
  (export "main" (func 1)))

which after instrumentation becomes

(module
  (type (;0;) (func))
  (func (;0;) (type 0)
    call 0)
  (func (;1;) (type 0)
    call 0)
  (global (;0;) (mut i32) (i32.const 0))
  (export "main" (func 1)))

today.

The correct model should be:

1. Pop the function address (for call_indirect);
2. Pop the arguments;
3. Push a function activation frame (this includes space for arguments, locals, return values and a reference to the module instance);

Module instance reference here in particular is something that would make stack depth accounting accurate in absence of the arguments, locals and return values.

Injecting the gas metering causes the function indices to shift. This causes any stacktraces using the name section to be wrong for any function with an index higher than the injected gas meter functions.

This is work-in-progress. No multi-value support yet, some tests are failing. I'm working on it.

The purpose of PR is to bring stack metering closer to the real world. Although Wasm values always take one abstract position on stack, real-world values do not work like that. For a legit code the difference is negligible, however, more care is needed to mitigate risks of potentially abusive code where an attacker may use that difference to abuse stack cost calculation (e.g. providing a function with several hundreds of wide f64 parameters).

Only sign_ext feature is supported from parity-wasm, the following aren't, but might be useful:

• atomics
• bulk
• multi_value
• simd

I wanted to do some experiments with enabling various features, but it fails with errors like this:

170 |         match opcode {
    |               ^^^^^^ pattern `&Simd(_)` not covered

Updates the requirements on wasmparser to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on wasmparser to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on parity-wasm to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on wasmparser to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hi, guys. As I can see here https://github.com/paritytech/wasm-instrument/blob/6a79d1d4b803c66c92ed91c0ee42d07f8e03c27f/src/gas_metering/backend.rs#L106-L110 Global is explicitly set to u64::MAX. I'd like to know the value of leftover gas instead of u64::MAX, is there a way to do it in the current version of your library?

Currently, we use parity-wasm both as a parser and encoder library for web assembly. However, this library is kind of outdated and only supports the wasm MVP properly.

The plan is to switch to the battle tested libraries wasmparser (for parsing) and wasm-encoder (for writing out the modified wasm). The main problem here is that those libraries don't have the required no_std support. So this is blocked until they have that or until an up-to-date fork exists. @Robbepop maintains such a fork here. However, it only added no_std support for wasmparser but it should be easy to support it for wasm-encoder (in the same repo) in a similar manner: https://github.com/Robbepop/wasm-tools/pull/1

Right now we re-export the parity-wasm crate so that our users can directly interact with those types. Some users (pallet-contract) even use those types implement some constraints and checks themselves on wasm modules. The same concept won't be possible because wasmparser is event driven and has no in-memory representation of a whole module like parity-wasm does.

Another hurdle is that we currently rely on the inability of parity-wasm to parse anything more than the wasm MVP to guard us against wasm modules that make use of features we don't want to support. I think this is a mistake: The parser should support everything that is standardized and this crate should represent the bottle neck of what we want to support. This is a natural place because we need to deal with all features in detail in order to implement a proper instrumentation.

This switch should shift the overall design so that we can accomplish all the checking and instrumentation steps in one pass over the module: We expose a single entry point like fn process<C: Config>(config: C). This Config will configure what is to be done in this single pass:

• Which wasm features to support or reject (MVP only/list of features)
• Which exports with which signatures are allowed
• Which imports with which signatures are allowed
• Check of memories (size and if imported or exported)
• Which instructions are supported (disallow floating point)
• Limit number of function parameters
• Limit the size of tables
• Limit the number of global variables
• Should we inject gas metering?
• Should we inject stack height limiting?
• Should we expose certain global variables?

The points listed above are basically what pallet-contracts is doing right now by directly depending on parity-wasm directly: https://github.com/paritytech/substrate/blob/master/frame/contracts/src/wasm/prepare.rs . We want to get rid of that code and move it to wasm-instrument through the Config we described above.

Doing this all in one pass and possibly in parallel (for std builds) could yield massive speedups. Right now the pallet-contracts needs multiple passes over a module to achieve all of that.