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

Consensus errors #1169

Open
holiman opened this issue Oct 2, 2018 · 2 comments
Open

Consensus errors #1169

holiman opened this issue Oct 2, 2018 · 2 comments
Assignees
Labels

Comments

@holiman
Copy link

holiman commented Oct 2, 2018

I'm eyeing through the EVM implementation, and thought I'd add any consensus errors that I can spot to this ticket. The ticket may contain some false positives, apologies in advance if that is the case

  1. Missing analysis of valid JUMPDESTs. The EVM does not allow jumping into a data-section, for example into the 32 bytes following a PUSH32. So if the code is
PUSH01 5b
PUSH1 01
JUMP

Then it appears that manticore evm would jump into the 'artificial' jumpdest 5b at byte 1 and continue execution.

  1. Missing JUMPDEST check. Apparently known already

  2. DELEGATECALL/CALLCODE quirks. It looks like DELEGATECALL passes the current address as sender here. That's how CALLCODE works, whereas DELEGATECALL should pass the original sender as sender.

  3. SELFDESTRUCT immediately deletes an address from the world: https://github.com/trailofbits/manticore/blob/master/manticore/platforms/evm.py#L1880 .

  4. SELFDESTRUCT adds deleted account to a list, possibly adding the same account multiple times if SELFDESTRUCT is performed several times: https://github.com/trailofbits/manticore/blob/master/manticore/platforms/evm.py#L1881

  5. (I'm unsure about this): I can't find where the stack value normalization happens. For example, the SUB operation returns potentially a negative integer. What happens if that negative integer is used as value for a CALL? Will a negative value be sent?

  6. 63/64ths rule does not seem implemented. Whenever a CALL type is made, the max allowed gas that is sent along to the child 63/64ths of the current gas.

@dguido
Copy link
Member

dguido commented Oct 2, 2018

Thanks for the code review. We filed a few issues yesterday related to testing and plan to address them in this release cycle. In particular, we think that adding support for the Constantinople changes will take only a day or two and should be in soon.

#1163
#1164
#1165
#1166
#1167
#1168

@feliam
Copy link
Contributor

feliam commented Oct 8, 2018

Hi holiman . Thank you or this. We are determined to up our correctness game so this is very welcome. I gave it a pass trying to address this issues.
1,2) FIXED. JUMPDEST, This was a known omission. #1172
3) Fixed here. #117
4) I'm researching why it should not be immediately deleted.. Will fix
5) Fixed here: #1180
6) Hopefully already correct. Need tests. We check that it does not send more than the source balance via a unsigned cmp

enough_balance = Operators.UGE(src_balance, value)

7) Not implemented. Also refunds are not implemented. Working on it...

We hope all this gets superseded by running the official XML tests.

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

No branches or pull requests

4 participants