-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add feature forbid-evm-reentrancy #863
add feature forbid-evm-reentrancy #863
Conversation
@sorpaas I applied your suggestions, thanks |
@sorpaas the CI is green, can you merge? |
* add feature forbid-evm-reentrancy * apply suggestions * link feature forbid-evm-reentrancy * clippy Conflicts: frame/evm/Cargo.toml
* add feature forbid-evm-reentrancy * apply suggestions * link feature forbid-evm-reentrancy * clippy
Hi @librelois, in which way could EVMRunner reentrancy be a risk? Can it not be interpreted as an internal transaction of the outer transaction? |
The EVMRunner implementation was not designed to auto handle reentrancy, if you need to made an evm call inside an evm execution you should explicitly use the subcall api. |
The goal of this PR is to provide a mechanism that guarantees that it's not possible to re-enter the EVM runner recursively.
We need this kind of security on moonbeam because in some special cases it may be possible: for example, with a precompile allowing to execute any XCM message locally, and the XCM to EVM feature, it becomes possible to re-enter the EVM runner recursively.
I coded this feature as an option because I don't know if it's annoying to impose it to all projects, even if I don't see why a project would need to allow a recursive re-entry in the evm runner.