Procedure Verification

[Latrasis]

Based on the ewasm interface and api we need a validator that checks:

1. That the code contains an execution guard
2. That a procedure does not contain external calls to:

• #call
• #callcode
• #calldelegate
• #storageStore
• #create
• #log{0,1,2,3,4}
• #selfDestruct

Interface

Interface should be as follows:

cap9_code_validate

Return if the code passes validation

Parameters

• code: &[u8] immutable reference to code memory location

Returns

• result: Result<(), CodeValidationError> returns an Ok() on success or a Err(CodeValidationError) on failure

Error Conditions

• CodeValidationError can be:
  • (1) CodeIsEmpty: code#length was zero
  • (2) CodeIsUnprotected: Code does not contain an execution guard header
  • (3) CodeIsIllegal: an illegal EEI interface call from list as described above.

Trap Conditions

• #getGasLeft reaches zero with kernel instance running out of gas
• #getBlockGasLimit becomes less than gas spent which means the block gas limit is reached

[JakeOShannessy]

Proof of concept of validating safe procedures and syscalls is done, although nothing is integrated into CI and the like yet. Currently the build stage for wasm projects is usually

1. rustc compiles the rust code to wasm.
2. wasm-build performs a series of modifications and optimisations to make it more suitable.

I propose, and have included in the proof of concept (currently on the validation branch) that we add a third step.

1. rustc compiles the rust code to wasm.
2. wasm-build performs a series of modifications and optimisations to make it more suitable.
3. cap9-build link in syscall code.

This is very similar in functionality to step 2, but does things that suit us instead. This has worked well, and will also help us when it comes to the execution guard, as it is a hook into the build process we didn't have before. One step still remaining is use a dummy wasm import that we will replace with this statically-linked syscall function. This will mean that rustc (at the start of the process) needs no knowledge of this, it just thinks it's linking to an external C library (or a web platform function, in the context of wasm).

[JakeOShannessy]

This is what a syscall looks like in wasm:

  (func $cap9_syscall_low (type $t0) (param $p0 i32) (param $p1 i32) (param $p2 i32) (param $p3 i32) (result i32)
    call $env.gasleft
    call $env.sender
    get_local $p0
    get_local $p1
    get_local $p2
    get_local $p3
    call $env.dcall)

The validator only allows $env.dcall to be called when it is in this form. The toolchain parts necessary to integrate this into contracts is complete, although in a very hacky proof-of-concept way, it needs plenty of cleaning and robustness.

The work flow is as follows:

1. Calls to pwasm_ethereum::write() (and the like) are replaced with cap9::write() when coding.
2. Under the hood all the cap9::* functions use cap9_syscall_low instead of dcall, write etc. Both cap9_syscall_low and write are compiled as external references. dcall and write are of course provided by the Ethereum runtime. cap9_syscall_low is not.
3. The code is compiled with rustc down to wasm. cap9_syscall_low, write etc. are left as imports from external locations.
4. wasm-build (from parity) is run on the wasm code. This does a number of things like modifying the memory setup and some optimizations.
5. cap9-build (from us) is run. This removes the external call to cap9_syscall_low (which of course doesn't exist in the Ethereum runtime) and statically links in a replacement. This replacement is the wasm code above. References to cap9_syscall_low now point to this instead.

[JakeOShannessy]

A note regarding ewasm and pwasm: all the work done here seems applicable to both, a notable exception being the names (and possibly signatures) of the Ethereum functions changing, but that's trivial.

[JakeOShannessy]

I'm blocked implementing this on pwasm due to the lack of the EXTCODECOPY instruction. This is specified in eWASM but it is not included in pwasm. I believe the relevant information for what is actually implemented by parity (i.e. the Ethereum node) is documented here: .

You can see fairly clearly in that file that only a subset of Ethereum instructions are implemented. It doesn't look unfeasible to implement, it's just a call from WASM to the Ethereum runtime. I'll have a look into, this means of course that we would have to build the parity node ourselves.

[JakeOShannessy]

Ok, so I was able to implement EXTCODESIZE, which is a little simpler than EXTCODECOPY because it just has to return a value, but it indicates if we wanted to implement these opcodes we could.

[JakeOShannessy]

Now that #153 has been addressed I can link this more properly into the kernel.