You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wasmtime accounts for "gas" by aborting once some amount of "fuel" has been consumed. It (likely?) tracks fuel by deducting the amount of fuel used by some "uninterruptible" block of code, then executes that "uninterruptible" block of code.
In the case where we exit normally (or even explicitly abort), this works fine.
In the case where we run out of gas, this also works fine because we'll simply record that all gas has been used.
In the case where some instruction in the middle of that block isn't quite uninterruptible, we may have issues.
Specifically:
Charge gas for the entire block.
Load A.
Load B -> Trap due to out-of-bounds access.
Load C
If this happens, we'll charge the wrong amount of gas. We need to:
Better understand what wasm does here.
Consider charging all remaining gas on out-of-bounds accesses like this. Callers could set hard limits on the amount of gas that can be charged if they need this to be recoverable.
The text was updated successfully, but these errors were encountered:
We've implemented our own gas accounting now and this will behave identically to the user calling the exit syscall: we'll use all gas from the rest of the wasm block.
Wasmtime accounts for "gas" by aborting once some amount of "fuel" has been consumed. It (likely?) tracks fuel by deducting the amount of fuel used by some "uninterruptible" block of code, then executes that "uninterruptible" block of code.
Specifically:
If this happens, we'll charge the wrong amount of gas. We need to:
The text was updated successfully, but these errors were encountered: