Skip to content

Fixed expectRevert being applied to calls to cheatcodes #1012

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.

Sign up for GitHub

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

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Fixed expectRevert being applied to calls to cheatcodes #1012

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
bc81b81
Fixed expectRevert being applied to calls to cheatcodes
lisandrasilva Apr 10, 2025
f65dbbb
Reverted changes to test_foundry_prove.py
lisandrasilva Apr 10, 2025
262c27c
Removed ignore calls to cheatcodes
lisandrasilva Apr 10, 2025
6ade197
Added test back to skip legacy tests
lisandrasilva Apr 10, 2025
9f5601b
Align expectRevert behavior in Kontrol with Foundry
lisandrasilva Apr 11, 2025
5fe872b
Merge branch 'master' into lis-fix-expectRevert
palinatolmach Apr 24, 2025
09c01aa
Merge branch 'master' into lis-fix-expectRevert
anvacaru Apr 25, 2025
91bd109
Merge branch 'master' into lis-fix-expectRevert
palinatolmach May 2, 2025
b9ee616
Merge branch 'master' into lis-fix-expectRevert
palinatolmach May 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 16 additions & 14 deletions src/kontrol/kdist/cheatcodes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -559,18 +559,6 @@ function expectRevert(bytes4 msg) external;
function expectRevert(bytes calldata msg) external;
```

All cheat code calls which take place while `expectRevert` is active are ignored.

```k
rule [cheatcode.call.ignoreCalls]:
<k> #cheatcode_call _ _ => .K ... </k>
<expectedRevert>
<isRevertExpected> true </isRevertExpected>
...
</expectedRevert>
[priority(35)]
```

We use the `#next[OP]` to identify OpCodes that can revert and insert a `#checkRevert` production used to examine the end of each call/create in KEVM.
The check will be inserted only if the current depth is the same as the depth at which the `expectRevert` cheat code was used.
WThe `#checkRevert` will be used to compare the status code of the execution and the output of the call against the expect reason provided.
Expand All @@ -579,23 +567,37 @@ WThe `#checkRevert` will be used to compare the status code of the execution and
rule [foundry.set.expectrevert.1]:
<k> #next [ _OP:CallOp ] ~> (.K => #checkRevert ~> #updateRevertOutput RETSTART RETWIDTH) ~> #execute ... </k>
<callDepth> CD </callDepth>
<wordStack> _ : _ : _ : _ : _ : RETSTART : RETWIDTH : _WS </wordStack>
<wordStack> _ : ACCTTO : _ : _ : _ : RETSTART : RETWIDTH : _WS </wordStack>
<expectedRevert>
<isRevertExpected> true </isRevertExpected>
<expectedDepth> CD </expectedDepth>
...
</expectedRevert>
requires ACCTTO =/=Int #address(FoundryCheat)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this check also have to be added to the rule [foundry.set.expectrevert.2] below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it's possible/likely to delegate a call to the cheatcode address?

Copy link
Contributor

@anvacaru anvacaru Apr 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into this and wrote two tests, one for delegatecall and one for staticcall calling a cheatcode.

The assertion at the end fails for delegatecall, whereas it does not fail for staticcall.

    function testDelegatecallCheatcodeReverts() external {
        (bool success, ) = VM_ADDRESS.delegatecall(
            abi.encodeWithSignature("roll(uint256)", 1337)
        );
        assertTrue(success);
        assertEq(block.number, 1337);
    }

    function testStaticcallcallCheatcode() external view {
        (bool success, ) = VM_ADDRESS.staticcall(
            abi.encodeWithSignature("roll(uint256)", 1337)
        );
        assertTrue(success);
        assertEq(block.number, 1337);
    }

So maybe it's worth adding the rule to cover staticcall for now. Next, in another issue/PR, we should check that Kontrol has the same behavior and ensure that delegating into VM_ADDRESS does not execute the cheat code.

@palinatolmach what do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it sounds good! Let's add a rule for staticcall here, and ensure that Kontrol behaves similarly wrt delegatecall as a follow-up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do it!
I also tried the following tests with Foundry:

function testIncrementAsNotOwner_2() public {
        vm.expectRevert(Unauthorized.selector);
        (bool success, ) = VM_ADDRESS.delegatecall(
            abi.encodeWithSignature("roll(uint256)", 1337)
        );
        upOnly.increment();
    }

And this test is passing when it shouldn't, since the function does not revert as expected. On the other hand, the following test fails:

function testIncrementAsNotOwner_3() public {
        vm.expectRevert(Unauthorized.selector);
        (bool success, ) = VM_ADDRESS.delegatecall(
            abi.encodeWithSignature("roll(uint256)", 1337)
        );
        vm.prank(address(0));
        upOnly.increment();
    }

It seems that delegatecall to VM_ADDRESS clears the expectRevert cheatcode.

[priority(32)]

rule [foundry.set.expectrevert.2]:
<k> #next [ _OP:CallSixOp ] ~> (.K => #checkRevert ~> #updateRevertOutput RETSTART RETWIDTH) ~> #execute ... </k>
<callDepth> CD </callDepth>
<wordStack> _ : _ : _ : _ : RETSTART : RETWIDTH : _WS </wordStack>
<wordStack> _ : ACCTTO : _ : _ : _ : RETSTART : RETWIDTH : _WS </wordStack>
<expectedRevert>
<isRevertExpected> true </isRevertExpected>
<expectedDepth> CD </expectedDepth>
...
</expectedRevert>
requires ACCTTO =/=Int #address(FoundryCheat)
[priority(32)]

rule [foundry.clear.expectrevert]:
<k> #next [ DELEGATECALL ] ~> (.K => #clearExpectRevert) ~> #execute ... </k>
<callDepth> CD </callDepth>
<wordStack> _ : ACCTTO : _ : _ : _ : _ : _ : _WS </wordStack>
<expectedRevert>
<isRevertExpected> true </isRevertExpected>
<expectedDepth> CD </expectedDepth>
...
</expectedRevert>
requires ACCTTO ==Int #address(FoundryCheat)
[priority(32)]
Copy link
Contributor Author

@lisandrasilva lisandrasilva Apr 11, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anvacaru and @palinatolmach, I added this rule, and now Kontrol mimics the same behavior as Foundry for the expectRevert cheatcode.
We still have to address cheatcodes being ignored when called through DELEGATECALL in another PR.


rule [foundry.set.expectrevert.3]:
Expand Down
1 change: 0 additions & 1 deletion src/tests/integration/test-data/foundry-prove-skip
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,6 @@ MockCallRevertTest.testMockCallRevertResetsMockCall()
MockCallRevertTest.testMockCallRevertWithCall()
MockCallRevertTest.testMockCallEmptyAccount()
OwnerUpOnlyTest.testFailIncrementAsNotOwner()
OwnerUpOnlyTest.testIncrementAsNotOwner()
OwnerUpOnlyTest.testIncrementAsOwner()
PlainPrankTest.testFail_startPrank_existingAlready()
PrankTest.testAddAsOwner(uint256)
Expand Down
Loading