{"id":22202887,"url":"https://github.com/logsem/cerise-stack","last_synced_at":"2025-03-25T01:47:34.960Z","repository":{"id":71519432,"uuid":"304284397","full_name":"logsem/cerise-stack","owner":"logsem","description":"Formalisation of stack safety properties on a capability machine with local and uninitialized capabilities","archived":false,"fork":false,"pushed_at":"2021-07-30T12:36:55.000Z","size":10386,"stargazers_count":1,"open_issues_count":0,"forks_count":1,"subscribers_count":10,"default_branch":"main","last_synced_at":"2025-01-30T03:28:08.016Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"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":"CITATION.cff","codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-10-15T10:03:50.000Z","updated_at":"2023-01-16T00:41:57.000Z","dependencies_parsed_at":null,"dependency_job_id":"55ecc90b-cdfe-452b-88d3-1574273361a5","html_url":"https://github.com/logsem/cerise-stack","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/logsem%2Fcerise-stack/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/logsem","download_url":"https://codeload.github.com/logsem/cerise-stack/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245383120,"owners_count":20606265,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","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":[],"created_at":"2024-12-02T16:38:42.569Z","updated_at":"2025-03-25T01:47:34.938Z","avatar_url":"https://github.com/logsem.png","language":"Coq","funding_links":[],"categories":[],"sub_categories":[],"readme":"This directory contains the Coq mechanization accompanying the submission\n\"Efficient and Provable Local Capability Revocation using Uninitialized\nCapabilities\".\n\n# Building and browsing the proofs\n\nYou need to have [opam](https://opam.ocaml.org/) \u003e= 2.0 installed. If this is\nthe first time you install opam, you additionally need to run `opam init`.\n\nThen, let us create a fresh *local* opam switch with everything needed. This\nwill install coq and iris in a local `_opam` directory:\n\n```\n   opam switch create -y --repositories=default,coq-released=https://coq.inria.fr/opam/released . ocaml-base-compiler.4.08.1\n   eval $(opam env)\n   opam install coqide  # optional, but useful to browse the proofs\n```\n\nThen, build the development:\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 1h to compile. In particular, the files\n`theories/examples/awkward_example{,_u}.v` can each take up to 25 minutes to\ncompile.\n\nIt is possible to run `make fundamental` to only build files up to the\nFundamental Theorem. This usually takes up 20 minutes.\n\n\nAfter building, one can use `coqide` to browse the proofs (ProofGeneral works as\nwell):\n\n``` \ncoqide theories/fundamental.v  # for instance\n```\n\n## Troubleshooting\n\nIf the opam invocation fails at some point, either remove the `_opam` directory\nand re-run the command (this will redo everything), or do `eval $(opam env)` and\nthen `opam install -y .` (this will continue from where it failed).\n\n## Cleanup\n\nIt is enough to remove the `_opam` directory to get rid of everything that has\nbeen installed for building the proofs.\n\nTo additionally get rid of *anything opam-related in general*, additionally\nremove `~/.opam` (if you just installed opam and do not plan on using it\nfurther).\n\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 1)  | machine\\_base.v                       |                                                      |\n| Permission and locality hierarchy (Fig 2)              | machine\\_base.v                       | `PermFlowsTo` - `LocalityFlowsTo`                    |\n| Operational semantics: reduction steps (Fig 3)         | cap\\_lang.v                           | `prim_step`                                          |\n| Operational semantics: instruction semantics (Fig 4)   | cap\\_lang.v                           | `exec`                                               |\n| Separation Logic Specifications (Fig 6)                | rules/*                               | e.g. `rules_Store.v\\wp_store_success_reg`            |\n| rclear Specification (Fig 6)                           | examples/stack\\_macros.v              | `rclear_spec`                                        |\n| Safety with Revocation (Fig 9)                         | logrel.v                              |                                                      |\n| Expression relation (Fig 9)                            | logrel.v                              | `interp_expr`                                        |\n| Register relation (Fig 9)                              | logrel.v                              | `interp_reg`                                         |\n| Value relation (Fig 9)                                 | logrel.v                              | `interp1` (and its fixpoint `interp`)                |\n| State relation (Fig 9)                                 | logrel.v                              | `region_state_*`                                     |\n| Standard State Transition System (Fig 10)              | region\\_invariants.v                  | `region_type` with `std_rel_pub` and `std_rel_priv`  |\n| Standard Resources (Fig 11)                            | region\\_invariants.v                  | inlined in `region_map_def`                          |\n| Mstd                                                   | sts.v                                 | `sts_full_std`, with the global gname (γs\\_std)      |\n| Mcus                                                   | sts.v                                 | `sts_full`, with the global gnames (γs\\_loc,γr\\_loc) |\n| stsCollection                                          | sts.v                                 | `sts_full_world`                                     |\n| sharedResources                                        | region\\_invariants.v                  | `region`                                             |\n| Fundamental Theorem of Logical Relations (Theorem 6.1) | fundamental.v                         | `fundamental_from_interp`                            |\n| Awkward Example: g1 (Fig 13)                           | examples/awkward\\_example\\_preamble.v | `awkward_preamble_instrs`                            |\n| Awkward Example: f1 (Fig 13)                           | examples/awkward\\_example\\_u.v        | `awkward_instrs`                                     |\n| Lemma 6.2                                              | examples/awkward\\_example\\_preamble.v | `awkward_preamble_spec`                              |\n| Theorem 6.3                                            | examples/awkward\\_example\\_adequacy.v | `awkward_example_adequacy`                           |\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- `machine_run.v`: Defines an executable version of the operational semantics,\n  allowing to use them as an interpreter to run a concrete machine\n  configuration.\n\n## Program logic\n\n- `monocmra.v`, `mono_ref.v`: Definition of monotonic references in Iris, used\n  to define the points-to predicate for memory addresses.\n\n- `region.v`: Auxiliary definitions to reason about consecutive range of\n  addresses and memory words.\n\n- `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.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\n\n- `multiple_updates.v`: Auxiliary definitions to reason about multiple updates\n  to a world.\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_uninitialized.v`: Lemmas for manipulating frozen standard\n  singleton resources. These are specifically for manipulating the resources\n  that are related to the interpretation of uninitialized capabilities.\n\n- `sts.v`: The definition of *stsCollection*, and associated lemmas.\n\n- `logrel.v`: The definition of the 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 6.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## Case studies\n\nIn the `examples` folder:\n\n- `stack_macros.v` and `stack_macros_u.v`: Specifications for some useful\n  macros, the former for a RWLX stack and the latter for a URWLX stack.\n\n- `scall.v`, `scall_u.v`: Specification of a safe calling convention for a RWLX\n  and URWLX stack respectively. Each 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- `lse.v` : A small and simple example that relies on local state encapsulation. \n\n- `malloc.v`: A simple malloc implementation, and its specification.\n\n- `awkward_example.v`, `awkward_example_u.v`: The proof of safety for the body\n  of the awkward example (the former using scall with stack clearing, the latter\n  using scallU without stack clearing).\n\n- `awkward_example_preamble.v`: Proof of safety of the preamble to the awkward\n  example (in which a closure to the body of the awkward example is dynamically\n  allocated). This corresponds to *Lemma 6.2*.\n\n- `awkward_example_adequacy.v`: Proof of correctness of the awkward example\n  against the operational semantics of the machine, *Theorem 6.3*.\n\n- `awkward_example_concrete.v`: A concrete instantiation of the correctness\n  theorem of the awkward example on a concrete machine, linked with a concrete\n  \"adversarial program\". Then, we also prove that this concrete machine\n  configurations indeed runs and gracefully halts.\n\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| SingleStep        | Instr Executable          |\n| Done Standby      | Instr NextI               |\n| Done Halted       | Instr Halted              |\n| Done Failed       | Instr Failed              |\n| Repeat _          | Seq _                     |\n\nIn the model:\n\n| *name in paper* | *name in mechanization* |\n|-----------------|-------------------------|\n| Frozen          | Static                  |\n| stsCollection   | full_sts_world          |\n| sharedResources | region                  |\n\nIn `scall.v` and `scall_u.v` : the scall macro is in both cases slightly unfolded, as it does not include the part of the calling convention which stores local state on the stack. That part is inlined into the awkward examples. \n\nIn `awkward_example_u.v`: in the mechanized version of the awkward example (uninitialized version), we clear the local stack frame in two stages: before the second call, we clear the part of the frame which is frozen during the first call, but passed to the adversary during the second call (i.e. a single address at the top of the first local stack frame), and before returning to the caller we clear the rest of the local stack frame (see Section 4.2 for further detail on clearing the local stack frame upon returning to an adversary call). \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flogsem%2Fcerise-stack","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flogsem%2Fcerise-stack","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flogsem%2Fcerise-stack/lists"}