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

Enable safely using doo files that were verified against other doo files #5335

Open
keyboardDrummer opened this issue Apr 19, 2024 · 4 comments
Labels
during 3: execution of incorrect program An bug in the verifier that allows Dafny to run a program that does not correctly implement its spec kind: bug Crashes, unsoundness, incorrect output, etc. If possible, add a `part:` label priority: not yet Will reconsider working on this when we're looking for work

Comments

@keyboardDrummer
Copy link
Member

keyboardDrummer commented Apr 19, 2024

If I have project A, A*, B and C, where B depends on A, C depends on B, and A and A* have the same type signature. Then if I build a.doo and a*.doo, then b.doo (passing in a.doo), and then c.doo (passing in b.doo, and a*.doo), then I can get Dafny to tell me everything verifies successfully, even though the verification done was not sound because a and a* may have different behavior.

Solution

  • When building a doo file, store a checksum of its sources in the output file.
  • When building a doo file, for each doo file passed to library, store a checksum of that dependency in the output in a list of dependency checksums.
  • When building a doo file, ensure that for each doo file passed to library, and each dependency checksum mentioned by that doo file, another doo passed to --library has that checksum.
@keyboardDrummer keyboardDrummer added kind: bug Crashes, unsoundness, incorrect output, etc. If possible, add a `part:` label during 3: execution of incorrect program An bug in the verifier that allows Dafny to run a program that does not correctly implement its spec labels Apr 19, 2024
@robin-aws
Copy link
Member

This is a good thing to be concerned about in general.

For the record some language ecosystems deal with this program at a higher-level of tooling instead. For example, .jar files don't include anything like this, and they are roughly equivalent to .doo files, but instead Maven/Gradle maintains checksums on packages.

I do think given Dafny's focus on verified correctness, and the fact that the solution looks cheap, this is worth implementing in the lower-level tooling, even if it ends up duplicative later on.

Note there's also a similar issue when you add translation to the dependency graph:

  1. Build A.doo to A.jar
  2. Build A*.doo to A*.jar
  3. Build B.doo to B.jar, assuming you provided --library A.doo when building B.doo
  4. Execute B.jar and A*.jar together, and get crashes/undefined behavior.

The solution to that may look similar, or it may be largely independent. It might be worth splitting it out as a separate issue.

When building a doo file, for each doo file passed to library, store a checksum of that dependency in the output in a list of dependency checksums.

I wonder if it would be more flexible to calculate and check this per module, so it's independent of the .doo bundling. That way you could change how libraries are grouped into .doo files without having to reverify/rebuild consuming libraries.

@keyboardDrummer
Copy link
Member Author

Thanks for the reply!

I wonder if it would be more flexible to calculate and check this per module, so it's independent of the .doo bundling. That way you could change how libraries are grouped into .doo files without having to reverify/rebuild consuming libraries.

Interesting idea. I'll mull it over.

@robin-aws
Copy link
Member

Note the solution to the translation integrity version of the problem can probably leverage the .dtr translation record concept we proposed on #5140 as well - if those files also include checksums on the translated code, we just need some extension to the target language environment to trigger checking them at loading/linking time.

@keyboardDrummer keyboardDrummer added the priority: not yet Will reconsider working on this when we're looking for work label Apr 23, 2024
@keyboardDrummer
Copy link
Member Author

Note there's also a similar issue when you add translation to the dependency graph

Good point!

I'm thinking of also adding a checksum of the input used to translation records generated when calling dafny translate, and then when you ingest a translation record using --translation-record, Dafny will verify that the same inputs are specified in --library, something like that.

Then when you do dafny translate java bSources --library A.doo --translation-record A.dtr it only works if you provide A.dtr, not if you provide A*.dtr, so it's slightly less like that you would then combine B.jar with A*.jar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
during 3: execution of incorrect program An bug in the verifier that allows Dafny to run a program that does not correctly implement its spec kind: bug Crashes, unsoundness, incorrect output, etc. If possible, add a `part:` label priority: not yet Will reconsider working on this when we're looking for work
Projects
None yet
Development

No branches or pull requests

2 participants