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

General Solution For Cex Reconstruction #334

Open
d-xo opened this issue Jul 28, 2023 · 0 comments
Open

General Solution For Cex Reconstruction #334

d-xo opened this issue Jul 28, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@d-xo
Copy link
Collaborator

d-xo commented Jul 28, 2023

Right now we have some fairly ad hoc solutions to reconstruct proper Cexs when we have lost information due to simplification.

A more general approach that would work for all cases could look like this:

  1. Gather all variables mentioned in the starting state (e.g. calldata, storage, context etc...)
  2. During simplification keep track of which rewrites have been applied (e.g. if we rewrote a == a || b == 6into True, we lost information that b == 6).
  3. If we get Sat, declare all variables from step 1 that are not present in the current query, assert concrete values for any variables mentioned in the cex, assert all facts that were simplified away in step 2.
  4. Call check-sat, now we should have a full and valid cex for that branch
@d-xo d-xo added the enhancement New feature or request label Jul 28, 2023
d-xo added a commit that referenced this issue Jul 28, 2023
Sometimes we get back a model that does not mention all variables that
are present in the input calldata buffer. This can happen if those
variables are not relevant to the branch that we are producing a model
for.

In this case we can simply set the values that remain symbolic afters
subsituting in our cex to some default value. We will still have issues
here if we have lost some constraints over those variables during
simplification, but it's better than what we're doing now (i.e. just
printing "Any" if we can't get a fully concrete model for calldata out).

A fully general (and hopefully correct) approach could look like:
#334
d-xo added a commit that referenced this issue Jul 28, 2023
Sometimes we get back a model that does not mention all variables that
are present in the input calldata buffer. This can happen if those
variables are not relevant to the branch that we are producing a model
for.

In this case we can simply set the values that remain symbolic afters
subsituting in our cex to some default value. We will still have issues
here if we have lost some constraints over those variables during
simplification, but it's better than what we're doing now (i.e. just
printing "Any" if we can't get a fully concrete model for calldata out).

A fully general (and hopefully correct) approach could look like:
#334
d-xo added a commit that referenced this issue Jul 28, 2023
Sometimes we get back a model that does not mention all variables that
are present in the input calldata buffer. This can happen if those
variables are not relevant to the branch that we are producing a model
for.

In this case we can simply set the values that remain symbolic afters
subsituting in our cex to some default value. We will still have issues
here if we have lost some constraints over those variables during
simplification, but it's better than what we're doing now (i.e. just
printing "Any" if we can't get a fully concrete model for calldata out).

A fully general (and hopefully correct) approach could look like:
#334
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant