{"id":14966244,"url":"https://github.com/logsem/cerise-stack-monotone","last_synced_at":"2026-01-21T08:12:09.231Z","repository":{"id":74946002,"uuid":"454808311","full_name":"logsem/cerise-stack-monotone","owner":"logsem","description":"Formalisation of temporal stack safety properties on a capability machine with local, uninitialized and directed capabilities.","archived":false,"fork":false,"pushed_at":"2022-04-11T10:48:50.000Z","size":11241,"stargazers_count":1,"open_issues_count":0,"forks_count":1,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-04-14T05:44:53.183Z","etag":null,"topics":["coq"],"latest_commit_sha":null,"homepage":"","language":"Coq","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/logsem.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-02-02T14:31:23.000Z","updated_at":"2024-03-16T19:22:22.000Z","dependencies_parsed_at":null,"dependency_job_id":"c181d92d-80ea-49f1-9ff1-6ccaae722466","html_url":"https://github.com/logsem/cerise-stack-monotone","commit_stats":{"total_commits":595,"total_committers":10,"mean_commits":59.5,"dds":0.6907563025210084,"last_synced_commit":"dff1909f6abc6de99c28d8f12e903b98dd76fb41"},"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/logsem/cerise-stack-monotone","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack-monotone","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack-monotone/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack-monotone/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack-monotone/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/logsem","download_url":"https://codeload.github.com/logsem/cerise-stack-monotone/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack-monotone/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28629922,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-21T04:47:28.174Z","status":"ssl_error","status_checked_at":"2026-01-21T04:47:22.943Z","response_time":86,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["coq"],"created_at":"2024-09-24T13:36:04.205Z","updated_at":"2026-01-21T08:12:09.217Z","avatar_url":"https://github.com/logsem.png","language":"Coq","funding_links":[],"categories":[],"sub_categories":[],"readme":"This directory contains the Coq mechanization accompanying the submission \"Le\nTemps des Cerises: Efficient Temporal Stack Safety on Capability Machines using\nDirected Capabilities\".\n\n# Building the proofs\n\n## Installing the dependencies\n\nYou need to have [opam](https://opam.ocaml.org/) \u003e= 2.0 installed.\n\nThe development is known to compile with Coq 8.12.0 and Iris 3.3.0. To install\nthose, two options:\n\n- **Option 1**: create a fresh *local* opam switch with everything needed:\n\n```\n   opam switch create -y --deps-only --repositories=default,coq-released=https://coq.inria.fr/opam/released .\n   eval $(opam env)\n```\n\n- **Option 2 (manual installation)**: if you already have an opam switch with\n  ocaml \u003e= 4.10.0:\n\n```\n    # Add the coq-released repo (skip if you already have it)\n    opam repo add coq-released https://coq.inria.fr/opam/released\n    # Install Coq 8.12.0 (skip if already installed)\n    opam install coq.8.12.0\n    opam update\n    opam install coq-iris.3.3.0\n```\n\n### Troubleshooting\n\nFor Option 1, if the invocation fails at some point, either remove the `_opam`\ndirectory and re-run the command (this will redo everything), or do `eval $(opam\nenv)` and then `opam install -y --deps-only .` (this will continue from where it\nfailed).\n\n## Building\n\n```\nmake -jN  # replace N with the number of CPU cores of your machine\n```\n\nWe recommend that you have **32Gb of RAM+swap**. Please be aware that the\ndevelopment takes around 2 to 3 hours to compile. In particular, the files\n`theories/examples/awkward_example_u.v` and `theories/examples/stack_object.v` \ncan each take up to 30 minutes to compile.\n\nIt is possible to run `make fundamental` to only build files up to the\nFundamental Theorem (and `make fundamental-binary` to build up until the binary\nFTLR, or `make full-abstraction` to build up until the full abstraction\ntheorem). Each usually takes up 20 minutes.\n\n## Checking for admits\n\nThe command `make check-admitted` will grep for `'admit\\|Admitted\\|ADMITTED'` in\nthe Coq files.\n\n# Documentation\n\nAfter building the development, documentation generated using Coqdoc can be\ncreated using `make html`. \n\nThen, browse the `html/toc.html` file.\n\nNote that we have included a copy of the generated html files as a supplemental material. \n\n# Organization\n\nFirst is a lookup table for the definitions in the paper.\n\n| *paper*                                                 | *file* or *folder*                | *name*                                                        |\n|---------------------------------------------------------|-----------------------------------|---------------------------------------------------------------|\n| Machine words, machine state and instructions (Fig 2)   | machine\\_base.v                   |                                                               |\n| Permission hierarchy (Fig 4)                            | machine\\_base.v                   | `PermFlowsTo`                                                 |\n| Operational semantics: instruction semantics (Fig 5)    | cap\\_lang.v                       | `exec`                                                        |\n| Standard State Transition System (Fig 6)                | region\\_invariants.v              | `region_type`/`std_rel_{pub}{priv}{pub_plus}`                 |\n| Logical relation (Fig 7)                                | logrel.v                          | `interp`/`interp_expression`/`interp_registers`               |\n| Theorem 4.1  (FTLR)                                     | fundamental.v                     | `fundamental_from_interp`                                     |\n| Assembly of Listing 7 (Fig 8)                           | downwards\\_lse{\\_preamble}.v      | `lse_instrs`/`downwards_lse_preamble_instrs`                  |\n| Theorem 4.2                                             | downwards\\_lse\\_adequacy.v        | `downwards_lse_adequacy`                                      |\n| Assembly of Listing 9 (Fig 9)                           | stack\\_object{\\_preamble}.v       | `stack_object_passing_instrs`/`stack_object_preamble_instrs`  |\n| Theorem 4.3                                             | stack\\_object\\_adequacy.v         | `obj_adequacy`                                                |\n| Theorem 6.1                                             | full\\_abstraction.v               | `compile_fully_abstract`                                      |\n| Definition 6.2 (forward simulation)                     | simulation.v                      | `forward_simulation`                                          |\n| Lemma 6.3                                               | simulation.v                      | `fsim_terminates`                                             |\n\nNext we describe the file organization of the implementation. \n\nThe organization of the `theories/` folder is as follows.\n\n## Operational semantics\n\n- `addr_reg.v`: Defines registers and the set of (finite) memory addresses.\n\n- `machine_base.v`: Contains the syntax (permissions, capability, instructions,\n  ...) of the capability machine.\n\n- `machine_parameters.v`: Defines a number of \"settings\" for the machine, that\n  parameterize the whole development (e.g. the specific encoding scheme for\n  instructions, etc.).\n\n- `cap_lang.v`: Defines the operational semantics of the machine, and the\n  embedding of the capability machine language into Iris.\n\n## Program logic (Unary)\n\n- `region.v`: Auxiliary definitions to reason about consecutive range of\n  addresses and memory words.\n\n- `rules/rules_base.v`: Contains some of the core resource algebras for the program\n  logic, namely the definition for points to predicates with permissions.\n\n- `rules/rules.v`: Imports all the Hoare triple rules for each instruction. These\n  rules are separated into separate files (located in the `rules/` folder).\n\n## Logical relation (Unary)\n\n- `multiple_updates.v`: Auxiliary definitions to reason about multiple updates\n  to a world.\n\n- `region_invariants_transitions.v`: Lemmas about standard transitions\n\n- `region_invariants.v`: Definitions for standard resources, and the shared\n  resources map *sharedResources*. Contains some lemmas for \"opening\" and\n  \"closing\" the map, akin to opening and closing invariants.\n\n- `region_invariants_revocation.v`: Lemmas for revoking standard resources\n  (setting *Temporary* invariants to a *Revoked* state).\n\n- `region_invariants_static.v`: Lemmas for manipulating frozen standard\n  resources.\n\n- `region_invariants_batch_uninitialized.v`: Lemmas for manipulating uninitialized \n  standard resources.\n\n- `region_invariants_allocation.v`: Lemmas for allocating a range of standard\n  resources.\n\n- `sts.v`: The definition of *stsCollection*, and associated lemmas. In particular:\n  priv/pub/temporal future world relations (all these definitions are \n  parametrized by the standard states and three relations over them transitions. \n  These are instantiated in `region_invariants.v`)\n\n- `logrel.v`: The definition of the unary logical relation.\n\n- `monotone.v`: Proof of the monotonicity of the value relation with regards to\n  public future worlds, and private future worlds for non local words.\n\n- `fundamental.v`: Contains *Theorem 4.1: fundamental theorem of logical\n  relations*. Each case (one for each instruction) is proved in a separate file\n  (located in the `ftlr/` folder), which are all imported and applied in this\n  file.\n\n## Proof sketch of the FTLR (Appendix A)\n\nThe correspondance between the lemmas and the Coq statements is as follows.\n\n| *paper*                                                 | *file* or *folder*                | *name*                                                        |\n|---------------------------------------------------------|-----------------------------------|---------------------------------------------------------------|\n| Lemma A.1 (address relative monotonicity)               | monotone.v                        | `interp_monotone_a`                                           |\n| Lemma A.2 (address relative weakening)                  | sts.v                             | `related_sts_a_weak_world`                                    |\n| Lemma A.3 (private monotonicity)                        | monotone.v                        | `interp_monotone_nm`                                          |\n| Theorem 4.1 (FTLR)                                      | fundamental.v                     | `fundamental_from_interp`                                     |\n\n## Binary Model (Appendix C)\n\nThe binary model is fully contained in the `binary_model` folder.\n\nThe binary model uses the same program logic as in the unary model, and a similar \nfamily of rules for the specification part of the refinement.\nThese rules are all in the `binary_model/rules_binary` folder. In particular, \nthe `binary_model/rules_binary/rules_binary_base.v` file contains the resource \nalgebra used for the specification part of the refinement.\n\n- `region_invariants{_XX}_binary.v`: Binary version of the *sharedResources*.\n\n- `logrel_binary.v`: Binary logical relation (Fig. 11).\n\n- `fundamental_binary.v`: Binary fundamental theorem of logical relations (Theorem C.1).\n  Each case is proved in a separate file located in `binary_model/ftlr_binary/`.\n\n## Case studies: Integrity\n\nIn the `examples` folder:\n\n- `macros/*` : Specifications for some useful macros\n\n- `macros/scall_u.v`: Specification of a safe calling convention for\n  a URWLX Directed stack. The specification is split up into two parts:\n  the prologue is the specification for the code before the jump, the epilogue\n  is the specification for the activation record.\n\n- `macros/malloc.v`: A simple malloc implementation, its specification, and\n  a proof that it is valid.\n\n- `downwards_lse{_preamble}{_adequacy}.v`: The assembly definition and proof of \n  *Listing 7*. The `preamble` file creates the closure, and the `adequacy` file\n  applies the adequacy of Iris weakest preconditions to prove the final theorem,\n  *Theorem 4.2*.\n\n- `stack_object{_preamble}{_adequacy}.v`: The assembly definition and proof of \n  *Listing 9*. The `preamble` file creates the closure, and the `adequacy` file\n  applies the adequacy of Iris weakest preconditions to prove the final theorem,\n  *Theorem 4.3*.\n\n- `awkward_example{_u}{_preamble}{_adequacy}.v`: The assembly definition and proof of \n  *Listing 5*. The `preamble` file creates the closure, and the `adequacy` file\n  applies the adequacy of Iris weakest preconditions to prove the final theorem.\n\n## Case studies: Confidentiality\n\nIn the `binary_model/examples_binary` folder:\n\n- `macros_binary` : Exports all macro specifications for the \"spec\" side of the\n  binary logical relation\n\n- `confidentiality{_adequacy}{_adequacy_theorem}.v`: The assembly definition and \n  proof of contextual equivalence of *Listing 8*. The adequacy files contain\n  the contextual equivalence statements and proofs. They apply the linking definitions\n  from `linking.v` (see below).\n\n## Linking\n\n- `linking.v`: Defines the general theory of components, well-formed components,\n  linking and contexts as presented in Appendix B.\n\n## Overlay semantics\n\nIn the `overlay` folder:\n\n- `lang.v`: Defines the overlay semantics. Note that we use a more restrictive\n  definition of *safe* words as explained in Appendix D due to some Coq\n  engineering issues.\n\n- `call.v`: Defines the implementation on the base machine of the call instruction.\n\n## Full abstraction theorem\n\n- `simulation.v`: Defines the general theory of forward simulations and prove\n  additional corollaries.\n  \n- `overlay_cap_lang_sim.v`: Proves the forward simulation between the overlay\n  semantics and the base capability machine. In particular, `sim` is the\n  simulation relation, and `overlay_to_cap_lang_fsim` is the proof of the\n  forward simulation.\n  \n- `full_abstraction.v`: Defines fully abstract compilation, and Theorem\n  `compile_fully_abstract` proves the full abstraction result of Theorem 6.1 in\n  the paper.\n\n# Differences with the paper\n\nSome definitions have different names from the paper.  \n\n*name in paper =\u003e name in mechanization*\n\nIn the operational semantics:\n\n| *name in paper*   | *name in mechanization*   |\n|-------------------|---------------------------|\n| Executable        | Instr Executable          |\n| Halted            | Instr Halted              |\n| Failed            | Instr Failed              |\n\nFor technical reasons (so that Iris considers a single instruction as an atomic step), \nthe execution mode is interweaved with the \"Instr Next\" mode, which reduces to a value.\nThe Seq _ context can then return and continue to the next instruction. The full expression \nfor an executing program is Seq (Instr Executable).\n\nIn the model:\n\n| *name in paper*     | *name in mechanization* |\n|---------------------|-------------------------|\n| Frozen              | Monostatic              |\n| stsCollection       | full_sts_world          |\n| sharedResources     | region                  |\n| Temporary           | Monotemporary           |\n| temporal transition | std_rel_pub_plus        |\n\nIn `scall_u.v` : the scall macro is slightly unfolded, as it does not include the part of \nthe calling convention which stores local state on the stack. That part is inlined into the \nexamples.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flogsem%2Fcerise-stack-monotone","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flogsem%2Fcerise-stack-monotone","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flogsem%2Fcerise-stack-monotone/lists"}