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

Call to precompile crashes echidna even when the compiler should prevent the call #606

Open
GalloDaSballo opened this issue Nov 19, 2024 · 3 comments

Comments

@GalloDaSballo
Copy link

GalloDaSballo commented Nov 19, 2024

Impact

I'd like to report an issue I'm running into when using Echidna with HEVM

When a precompile is the target to a call, HEVM reverts, even when Echidna should not be calling the precompile, but it's just getting the precompile size

POC

The template uses Chimera so you can run any Fuzzer / FV tool

https://github.com/Recon-Fuzz/hevm-precompile-crash-unexpected

Run with Foundry -> Reverts as the compiler protects us from calling the precompile
Run with Echidna -> Crashes HEVM even though I would expect the compiler to prevent the call to the precompile

Call 1

    function doACall() public {
        uint256 size = address(0x0a).code.length;
        size + 1;
    }

The crash here is expected, we're calling the precompile directly and it's unimplemented

Call 2

    function doACall() public {
        uint256 res = IERC20(address(0x0a)).balanceOf(address(this));
        res + 1;
    }

The crash here is unexpected, shouldn't the compiler inserted check cause a revert before we call the precompile?

Call 3

    function doACall() public {
        uint256 size = address(0x0a).code.length;
        size + 1;
    }

Surprisingly, the call here doesn't revert

Conclusion

Maybe I'm missing something, but I would expect the compiler to prevent Echidna from calling the precompile hence prevent the crash, however, that's not the case

What would you advise to allow me to use echidna with a set of contracts that allow arbitrary inputs and calls?

@elopez
Copy link
Contributor

elopez commented Nov 19, 2024

For further context on call # 2, the compiler no longer inserts an extcodesize check if the function returns data, so it's also expected as in case # 1 - ethereum/solidity#12204. The last version with the check was solc 0.8.9

@msooseth
Copy link
Collaborator

@elopez do you wanna take a look at this? I think I'm not enough of an expert (yet) at these. Otherwise, I'll try to take a shot at it later :)

@elopez
Copy link
Contributor

elopez commented Dec 10, 2024

@msooseth I think the problem is that the 0xa precompile is unimplemented. Currently that triggers an internalError https://github.com/ethereum/hevm/blob/main/src/EVM.hs#L1202

When I looked at the precompile, it didn't seem like something straightforward to implement; it mentions blobs https://www.evm.codes/precompiled?fork=cancun#0x0a

Maybe providing a placeholder implementation that always reverts would be enough for most users here? Or maybe we can relax the internalError to a revert?

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

No branches or pull requests

3 participants