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

Tracking formal verification status #140

Open
Tracked by #242
emmanuelsearch opened this issue Mar 5, 2024 · 6 comments
Open
Tracked by #242

Tracking formal verification status #140

emmanuelsearch opened this issue Mar 5, 2024 · 6 comments
Labels
docs Improvements or additions to documentation formal Formal verification

Comments

@emmanuelsearch
Copy link
Contributor

emmanuelsearch commented Mar 5, 2024

Based on the current use of hax and with regards to our draft manifesto, the question arises of where/how to track where we currently are at, now that initial integration has begun e.g. with #126.

@ROMemories ROMemories added the formal Formal verification label Mar 5, 2024
@emmanuelsearch
Copy link
Contributor Author

emmanuelsearch commented Mar 5, 2024

to give a concrete example: based on https://github.com/future-proof-iot/RIOT-rs/blob/main/src/riot-rs-runqueue/proofs/fstar/extraction/Makefile how/where should we express (for laypeople) what verification(s) are currently provided by CI for the scheduler? @W95Psp @franziskuskiefer obviously we'd very much value your suggestions on this ;)

@emmanuelsearch emmanuelsearch added the docs Improvements or additions to documentation label Mar 11, 2024
@franziskuskiefer
Copy link

So do we have panic freedom already? If yes, then you should think about the contracts (pre- and post-conditions) the functions have and if there's something interesting that should be proven.
In parallel, adding more crates to the extraction, lax typechecking, etc. pipeline.

To the documentation, I think panic freedom should be documented when the extracted code typechecks in F*.
Additional properties should then come from the contracts the functions get and get described accordingly.

@emmanuelsearch
Copy link
Contributor Author

@franziskuskiefer thanks for the input. A more basic question then: what is the fundamental difference between typechecking and lax typechecking ? (I seem to remember @W95Psp hinting that RunQueue was lax typechecking already, but I am not sure if my memory plays tricks on me, or how to check that myself ;)

@franziskuskiefer
Copy link

I think the easiest description is

  • lax typechecking -> valid F* code is generated and all dependencies (like from the Rust core library) are defined
  • typechecking -> panic freedom (F* proved that no panic occurs in the code)

@kaspar030 kaspar030 mentioned this issue Apr 10, 2024
57 tasks
@ROMemories
Copy link
Collaborator

@W95Psp Could you detail the steps that would now be required to typecheck the riot-rs-runqueue crate and prove panic-freedom? The hax.yml CI workflow currently only does lax typechecking if I understand correctly.

@ROMemories
Copy link
Collaborator

The Makefile we had indeed only did lax typechecking (e.g., symbol resolution checking). #404 updated the hax setup; CI is still configured to only do lax typechecking, but it would now be easy to enable full typechecking which, if successful, proves panic-freedom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Improvements or additions to documentation formal Formal verification
Projects
None yet
Development

No branches or pull requests

3 participants