Skip to content
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

Merged

Conversation

librelois
Copy link
Contributor

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.

@librelois librelois requested a review from sorpaas as a code owner September 20, 2022 15:19
@librelois
Copy link
Contributor Author

@sorpaas I applied your suggestions, thanks

@librelois
Copy link
Contributor Author

@sorpaas the CI is green, can you merge?

@sorpaas sorpaas merged commit 6576c56 into polkadot-evm:master Oct 3, 2022
librelois added a commit to moonbeam-foundation/frontier that referenced this pull request Oct 3, 2022
* add feature forbid-evm-reentrancy

* apply suggestions

* link feature forbid-evm-reentrancy

* clippy
Conflicts:
	frame/evm/Cargo.toml
abhijeetbhagat pushed a commit to web3labs/frontier that referenced this pull request Jan 11, 2023
* add feature forbid-evm-reentrancy

* apply suggestions

* link feature forbid-evm-reentrancy

* clippy
@clostao
Copy link

clostao commented Feb 21, 2023

Hi @librelois, in which way could EVMRunner reentrancy be a risk? Can it not be interpreted as an internal transaction of the outer transaction?

@librelois
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants