-
Notifications
You must be signed in to change notification settings - Fork 63
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
Implement a memory invalidation pass for jvm_verify #1069
Conversation
It's likely that this PR in its current state will horribly break the ECDSA proof. If that's the case, then I should probably implement the additional features discussed in the #900 thread before merging this PR. I'll keep this in draft state until I know whether that will be necessary. |
The CI results show everything as passing, yet on my local repo |
It looks like Line 171 in 9d812c9
|
It looks like I was mistaken: Line 171 in 9d812c9
This kind of defeats the purpose of PR #932 and means that issue #901 is not really fixed. |
I've now opened #1070 to see if we can re-enable all the integration tests that were disabled in CI without explanation. |
Currently these tests are configured as known failures; the tests will need to be updated when the bugs are fixed.
This ensures that executing an incomplete override, which omits some field modifications that are not mentioned in the override spec, will not lead to unsoundness. Fixes #900.
2ea9f9e
to
ba02fb7
Compare
Instead of doing an invalidation pass, I think we're going to want to implement per-field write permission bits in the crucible-jvm memory model. The explicit user-provided frame conditions required by this PR are just too onerous, and yield overrides that are not as generally applicable as we want. |
A memory invalidation pass is not the approach we want to take to fix this problem; we instead want to implement write permissions in the crucible-jvm memory model. |
This is analogous to what was done for LLVM in #549, and prevents unsoundness caused by executing overrides with incomplete specs.
Fixes #900.
Note that this PR does not implement all the features exactly as they were discussed in the comment thread for #900: Currently, fields without points-to declarations in the post-state section are invalidated, rather than asserted to be equal to their initial values. The plan is to implement that feature separately, by having the same setup spec translate to a slightly different
MethodSpec
value when post-state points-to declarations are absent.