Merge remote-tracking branch 'origin/main' into verify-intrinsics

Since intrinsics file has been deleted, we will have to reapply the
patch.

Conflicts:
 - library/core/src/intrinsics.rs

.github/pull_requests.toml

@@ -12,5 +12,11 @@ members = [
     "jaisnan",
     "patricklam",
     "ranjitjhala",
-    "carolynzech"
+    "carolynzech",
+    "robdockins",
+    "HuStmpHrrr",
+    "Eh2406",
+    "jswrenn",
+    "havelund",
+    "jorajeev"
 ]

.github/workflows/kani.yml

@@ -65,3 +65,17 @@ jobs:
       - name: Test Kani script (In Repo Directory)
         working-directory: ${{github.workspace}}/head
         run: scripts/run-kani.sh --kani-args --harness ptr::verify::check_read_u128 --harness ptr --output-format=terse
+
+      # Step 4: Run list on the std library and add output to job summary
+      - name: Run Kani List
+        run: head/scripts/run-kani.sh --run list --path ${{github.workspace}}/head
+
+      - name: Add Kani List output to job summary
+        uses: actions/github-script@v6
+        with:
+          script: |
+            const fs = require('fs');
+            const kaniOutput = fs.readFileSync('${{github.workspace}}/head/kani_list.txt', 'utf8');
+            await core.summary
+              .addRaw(kaniOutput)
+              .write();

README.md

@@ -7,24 +7,23 @@
 This repository is a fork of the official Rust programming
 language repository, created solely to verify the Rust standard
 library. It should not be used as an alternative to the official
-Rust releases. The repository is tool agnostic and welcomes the addition of 
+Rust releases. The repository is tool agnostic and welcomes the addition of
 new tools.
 
 The goal is to have a verified [Rust standard library](https://doc.rust-lang.org/std/) and prove that it is safe.
 1. Contributing to the core mechanism of verifying the rust standard library
 2. Creating new techniques to perform scalable verification
 3. Apply techniques to verify previously unverified parts of the standard library.
 
-## [Kani](https://github.com/model-checking/kani)
+For that we are launching a contest that includes a series of challenges that focus on verifying
+memory safety and a subset of undefined behaviors in the Rust standard library.
+Each challenge describes the goal, the success criteria, and whether it has a financial award to be awarded upon its
+successful completion.
 
-The Kani Rust Verifier is a bit-precise model checker for Rust.
-Kani verifies:
-* Memory safety (e.g., null pointer dereferences)
-* User-specified assertions (i.e `assert!(...)`)
-* The absence of panics (eg., `unwrap()` on `None` values)
-* The absence of some types of unexpected behavior (e.g., arithmetic overflows).
+See [our book](https://model-checking.github.io/verify-rust-std/intro.html) for more details on the challenge rules
+and the list of existing challenges.
 
-You can find out more about Kani from the [Kani book](https://model-checking.github.io/kani/) or the [Kani repository on Github](https://github.com/model-checking/kani).
+We welcome everyone to participate!
 
 ## Contact
 
@@ -40,7 +39,7 @@ See [SECURITY](https://github.com/model-checking/kani/security/policy) for more
 Kani is distributed under the terms of both the MIT license and the Apache License (Version 2.0).
 See [LICENSE-APACHE](https://github.com/model-checking/kani/blob/main/LICENSE-APACHE) and [LICENSE-MIT](https://github.com/model-checking/kani/blob/main/LICENSE-MIT) for details.
 
-## Rust
+### Rust
 Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.
 
 See [the Rust repository](https://github.com/rust-lang/rust) for details.

doc/src/SUMMARY.md

@@ -25,5 +25,5 @@
   - [10: Memory safety of String](./challenges/0010-string.md)
   - [11: Safety of Methods for Numeric Primitive Types](./challenges/0011-floats-ints.md)
   - [12: Safety of `NonZero`](./challenges/0012-nonzero.md)
-
+  - [13: Safety of `CStr`](./challenges/0013-cstr.md)
 

doc/src/challenge_template.md

@@ -3,8 +3,9 @@
 - **Status:** *One of the following: \[Open | Resolved | Expired\]*
 - **Solution:** *Option field to point to the PR that solved this challenge.*
 - **Tracking Issue:** *Link to issue*
-- **Start date:** *YY/MM/DD*
-- **End date:** *YY/MM/DD*
+- **Start date:** *YYYY/MM/DD*
+- **End date:** *YYYY/MM/DD*
+- **Reward:** *TBD*[^reward]
 
 -------------------
 
@@ -49,3 +50,4 @@ Note: All solutions to verification challenges need to satisfy the criteria esta
 in addition to the ones listed above.
 
 [^challenge_id]: The number of the challenge sorted by publication date.
+[^reward]: Leave it as TBD when creating a new challenge. This should only be filled by the reward committee.

doc/src/challenges/0001-core-transmutation.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#19](https://github.com/model-checking/verify-rust-std/issues/19)
-- **Start date:** 2024-06-12
-- **End date:** 2024-12-10
+- **Start date:** *2024/06/12*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0002-intrinsics-memory.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#16](https://github.com/model-checking/verify-rust-std/issues/16)
-- **Start date:** *24/06/12*
-- **End date:** *24/12/10*
+- **Start date:** *2024/06/12*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0003-pointer-arithmentic.md

@@ -1,10 +1,10 @@
 # Challenge 3: Verifying Raw Pointer Arithmetic Operations
 
 - **Status:** Open
-- **Solution:**
 - **Tracking Issue:** [#76](https://github.com/model-checking/verify-rust-std/issues/76)
-- **Start date:** 24/06/24
-- **End date:** 24/12/10
+- **Start date:** *2024/06/24*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0004-btree-node.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#77](https://github.com/model-checking/verify-rust-std/issues/77)
-- **Start date:** *2024-07-01*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/07/01*
+- **End date:** *2025/04/10*
+- **Reward:** *10,000 USD*
 
 -------------------
 

doc/src/challenges/0005-linked-list.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#29](https://github.com/model-checking/verify-rust-std/issues/29)
-- **Start date:** *24/07/01*
-- **End date:** *24/12/10*
+- **Start date:** *2024/07/01*
+- **End date:** *2025/04/10*
+- **Reward:** *5,000 USD*
 
 -------------------
 
@@ -23,7 +24,7 @@ The memory safety of the following public functions that iterating over the inte
 
 | Function | Location |
 |---------|---------|
-|clearn | alloc::collections::linked_list |
+|clear| alloc::collections::linked_list |
 |contains| alloc::collections::linked_list |
 |split_off| alloc::collections::linked_list |
 |remove| alloc::collections::linked_list |

doc/src/challenges/0006-nonnull.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#53](https://github.com/model-checking/verify-rust-std/issues/53)
-- **Start date:** *2024-08-16*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/08/16*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0007-atomic-types.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#83](https://github.com/model-checking/verify-rust-std/issues/83)
-- **Start date:** *2024-10-30*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/10/30*
+- **End date:** *2025/04/10*
+- **Reward:** *10,000 USD*
 
 -------------------
 

doc/src/challenges/0008-smallsort.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#56](https://github.com/model-checking/verify-rust-std/issues/56)
-- **Start date:** *2024-08-17*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/08/17*
+- **End date:** *2025/04/10*
+- **Reward:** *10,000 USD*
 
 -------------------
 

doc/src/challenges/0009-duration.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#72](https://github.com/model-checking/verify-rust-std/issues/72)
-- **Start date:** *2024-08-20*
-- **End date:** *2024-12-20*
+- **Start date:** *2024/08/20*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0010-string.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#61](https://github.com/model-checking/verify-rust-std/issues/61)
-- **Start date:** *2024-08-19*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/08/19*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0011-floats-ints.md

@@ -3,8 +3,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#59](https://github.com/model-checking/verify-rust-std/issues/59)
-- **Start date:** *2024-08-20*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/08/20*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0012-nonzero.md

@@ -2,8 +2,9 @@
 
 - **Status:** Open
 - **Tracking Issue:** [#71](https://github.com/model-checking/verify-rust-std/issues/71)
-- **Start date:** *2024-08-23*
-- **End date:** *2024-12-10*
+- **Start date:** *2024/08/23*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
 
 -------------------
 

doc/src/challenges/0013-cstr.md

@@ -0,0 +1,86 @@
+# Challenge 13: Safety of `CStr`
+
+- **Status:** Open
+- **Solution:**
+- **Tracking Issue:** [#150](https://github.com/model-checking/verify-rust-std/issues/150)
+- **Start date:** *2024/11/04*
+- **End date:** *2025/04/10*
+- **Reward:** *N/A*
+
+-------------------
+## Goal
+
+Verify that `CStr` safely represents a borrowed reference to a null-terminated array of bytes sequences similar to
+the C string representation.
+
+## Motivation
+
+The `CStr` structure is meant to be used to build safe wrappers of FFI functions that may leverage `CStr::as_ptr`
+and the unsafe `CStr::from_ptr` constructor to provide a safe interface to other consumers.
+It provides safe methods to convert `CStr` to a Rust `&str` by performing UTF-8 validation, or into an owned `CString`.
+
+Any issue with this structure or misusage of its unsafe methods could trigger an invalid memory access, which poses
+a security risk for their users.
+
+## Description
+
+The goal of this challenge is to ensure the safety of the `CStr` struct implementation.
+First, we need to specify a safety invariant that captures the essential safety properties that must be maintained.
+
+Next, we should verify that all the safe, public methods respect this invariant.
+For example, we can check that creating a `CStr` from a byte slice with method `from_bytes_with_nul` will only yield
+safe values of `CStr`.
+
+Finally, for unsafe methods like `from_ptr()` and `from_bytes_with_nul_unchecked`, we need to specify appropriate safety contracts.
+These contracts should ensure no undefined behavior occurs within the unsafe methods themselves,
+and that they maintain the overall safety invariant of `CStr` when called correctly.
+
+### Assumptions
+
+- Harnesses may be bounded.
+
+### Success Criteria
+
+1. Implement the `Invariant` trait for `CStr`.
+
+2. Verify that the `CStr` safety invariant holds after calling any of the following public safe methods.
+
+| Function               | Location           |
+|------------------------|--------------------|
+| `from_bytes_until_nul` | `core::ffi::c_str` |
+| `from_bytes_with_nul`  | `core::ffi::c_str` |
+| `count_bytes`          | `core::ffi::c_str` |
+| `is_empty`             | `core::ffi::c_str` |
+| `to_bytes`             | `core::ffi::c_str` |
+| `to_bytes_with_nul`    | `core::ffi::c_str` |
+| `bytes`                | `core::ffi::c_str` |
+| `to_str`               | `core::ffi::c_str` |
+| `as_ptr`               | `core::ffi::c_str` |
+
+3. Annotate and verify the safety contracts for the following unsafe functions:
+
+| Function                       | Location            |
+|--------------------------------|---------------------|
+| `from_ptr`                     | `core::ffi::c_str`  |
+| `from_bytes_with_nul_uncheked` | `core::ffi::c_str`  |
+| `strlen`                       | `core::ffi::c_str`  |
+
+4. Verify that the following trait implementations for the `CStr` type are safe:
+
+
+| Trait                               | Implementation Location |
+|-------------------------------------|-------------------------|
+| `CloneToUninit` [^unsafe-fn]        | `core::clone`           |
+| `ops::Index<ops::RangeFrom<usize>>` | `core::ffi::c_str`      |
+
+[^unsafe-fn]: Unsafe functions will require safety contracts.
+
+All proofs must automatically ensure the absence of the following undefined behaviors [ref](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md):
+
+- Accessing (loading from or storing to) a place that is dangling or based on a misaligned pointer.
+- Performing a place projection that violates the requirements of in-bounds pointer arithmetic.
+- Mutating immutable bytes.
+- Accessing uninitialized memory.
+
+Note: All solutions to verification challenges need to satisfy the criteria established in the
+[challenge book](../general-rules.md) in addition to the ones listed above.

doc/src/intro.md

@@ -6,12 +6,22 @@ library](https://doc.rust-lang.org/std/). The goal of this is
 to provide automated verification that can be used to verify that a
 given Rust standard library implementation is safe.
 
+Verifying the Rust libraries is difficult because:
+1. Lack of a specification,
+2. Lack of an existing verification mechanism in the Rust ecosystem,
+3. The large size of the verification problem,
+4. The unknowns of scalable verification.
+
+Given the magnitude and scope of the effort, we believe this should be a community owned effort.
+For that, we are launching a contest that includes a series of challenges that focus on verifying
+memory safety and a subset of undefined behaviors in the Rust standard library.
+
 Efforts are largely classified in the following areas:
 
 1. Contributing to the core mechanism of verifying the rust standard library
 2. Creating new techniques to perform scalable verification
 3. Apply techniques to verify previously unverified parts of the standard library.
 
+There is a financial award tied to each challenge per its specification, which is awarded upon its successful completion.
 
-We encourage everyone to watch this repository to be notified of any
-changes.
+We encourage everyone to watch this repository to be notified of any changes.

doc/src/tool_template.md

@@ -20,12 +20,12 @@ _Please list the license(s) that are used by your tool, and if to your knowledge
 
 ## Steps to Use the Tool
 
-1. [First Step]
-2. [Second Step]
-3. [and so on...]
+1. \[First Step\]
+2. \[Second Step\]
+3. \[and so on...\]
 
 ## Artifacts
-_If there are noteworthy examples of using the tool to perform verificaiton, please include them in this section.Links, papers, etc._
+_If there are noteworthy examples of using the tool to perform verification, please include them in this section.Links, papers, etc._
 
 ## CI & Versioning
 _Please describe how you version the tool and how it will be supported in CI pipelines._