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

JVM methods that write to static fields not mentioned in the spec can be unsound #1066

Closed
brianhuffman opened this issue Feb 6, 2021 · 0 comments · Fixed by #1293
Closed
Assignees
Labels
subsystem: crucible-jvm Issues related to Java verification with crucible-jvm unsoundness Issues that can lead to unsoundness or false verification

Comments

@brianhuffman
Copy link
Contributor

This is an issue that is closely related to #900. While that issue is about fields of allocated objects that don't have a final value specified, this one is instead about static fields, which are more like globals. If executing a method causes a specific static field to be written to, but the spec doesn't mention that particular static field at all, then using the resuling override in other proofs can be unsound.

Issue #900 can be addressed by doing an invalidation pass after applying the override: For every allocated object mentioned in the spec, each instance field that does not have a final value specified can be invalidated by resetting it to an uninitialized state.

However, for static fields, we can't do the same thing (or at least, we don't want to). If we apply an override for a method, we don't want to invalidate every static field for every class that wasn't mentioned in the spec, because this would destroy the usefulness of compositional proof. When we execute an override, it should leave all unmentioned static fields exactly as they were. But during verification, we also need to make sure that the method doesn't actually modify any unmentioned static fields.

One approach might be to add a proof obligation for each static field, asserting that the contents before and after are unchanged. But this wouldn't scale very well, because the number of static fields in existence might be very large, consisting of all fields from all classes that the translator knows about.

Probably what we need to do is to add an explicit write permission bit to static fields in the crucible-jvm memory model. Every putstatic instruction should check this bit and assert that it is true. When performing a verification, we can then set the permissions so that the only writable static fields are the ones explicitly mentioned in the spec. This way we can ensure that symbolic execution will never modify any parts of global state that we don't know about.

@brianhuffman brianhuffman added subsystem: crucible-jvm Issues related to Java verification with crucible-jvm unsoundness Issues that can lead to unsoundness or false verification labels Feb 6, 2021
@brianhuffman brianhuffman self-assigned this Feb 6, 2021
@mergify mergify bot closed this as completed in #1293 May 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
subsystem: crucible-jvm Issues related to Java verification with crucible-jvm unsoundness Issues that can lead to unsoundness or false verification
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant