search

ewasm / design

Ewasm Design Overview and Specification
Apache License 2.0
1.02k stars 125 forks source link

Ensure that memory expansion (grow_memory) aborts on failure #177

Open axic opened 5 years ago

axic commented 5 years ago

While the metering "spec" calls for prepending grow_memory with a gas check, the grow_memory opcode can still return a failure when enough gas is present, but not enough memory is available.

@d1m0 has suggested this is an issue.

I propose that instead of only injecting a gas check, grow_memory should be wrapped in a special check which causes a panic (or OOG) on the client.

I'm not sure what is the best behaviour (panic, OOG or something else?), but likely leaving it alone is wrong, because that gives an opportunity to the contract developer to check for the return value of grow_memory and create diverging behaviours.

poemm commented 5 years ago

We have discussed options of disallowing memory.grow, or bounding Wasm memory with gas charges.

The WebAssembly spec Section 7.2 Implementation Limitations lists many more things. There are some subtle things involving recursion.

d1m0 commented 5 years ago

In order to ensure non-determinism, I don't think we want OOG. It sounds strange that if we have sufficient gas for a given memory write, some clients may still throw an OOG because they are temporarily low on "physical" memory.

poemm commented 5 years ago

The option to bound Wasm memory with gas would involve the honest majority of miners keeping the gas limit low enough so that their clients can easily handle any amount of Wasm memory that is within the gas limit. EVM uses a similar mechanism.

axic commented 5 years ago

It is not only the gas limit, but a combination of gas limit and gas price.

There are two ways to cause memory allocation systematically fail while still not running out of gas: a) wrong gas cost (or not using the quadratic logic for memory usage) b) wrong combination of gas price + gas limit

The variable in option b) can be influenced by the miners without a hard fork, while a) requires a hard fork.

gcolvin commented 5 years ago

I mentioned in the Gitter channel that long before most systems run out of virtual memory they will thrashing so badly as to be useless. So I'm not sure this problem that is going to happen in practice.