Skip to content

Commit 5fc28bd

Browse files
committed
Merge remote-tracking branch 'origin/main' into verify-intrinsics
2 parents 9c81d9c + dc862c4 commit 5fc28bd

File tree

13 files changed

+633
-30
lines changed

13 files changed

+633
-30
lines changed

.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,7 @@ Session.vim
2020
/book/
2121
/build/
2222
/target
23+
library/target
2324
*.rlib
2425
*.rmeta
2526
*.mir

doc/src/SUMMARY.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@
33
[Introduction](intro.md)
44

55
- [General Rules](./general-rules.md)
6-
- [Challenge Template](./template.md)
7-
- [Tool application](./todo.md)
6+
- [Challenge Template](./challenge_template.md)
7+
- [Tool Application Template](./tool_template.md)
88

99
- [Verification Tools](./tools.md)
1010
- [Kani](./tools/kani.md)
File renamed without changes.

doc/src/general-rules.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ A proposed solution to a verification problem will only **be reviewed** if all t
3939
* The contribution must be automated and should be checked and pass as part of the PR checks.
4040
* All tools used by the solution must be in [the list of accepted tools](tools.md#approved-tools),
4141
and previously integrated in the repository.
42-
If that is not the case, please submit a separate [tool application first](todo.md).
42+
If that is not the case, please submit a separate [tool application first](./general-rules.md#tool-applications).
4343
* There is no restriction on the number of contributors for a solution.
4444
Make sure you have the rights to submit your solution and that all contributors are properly mentioned.
4545
* The solution cannot impact the runtime logic of the standard library unless the change is proposed and incorporated
@@ -56,7 +56,7 @@ The type of obstacles users face may depend on which part of the standard librar
5656
Everyone is welcome to submit new challenge proposals for review by our committee.
5757
Follow the following steps to create a new proposal:
5858

59-
1. Create a tracking issue using the Issue template [Challenge Proposal](template.md) for your challenge.
59+
1. Create a tracking issue using the [challenge template](./challenge_template.md) for your challenge.
6060
2. In your fork of this repository do the following:
6161
1. Copy the template file (`book/src/challenge_template.md`) to `book/src/challenges/<ID_NUMBER>-<challenge-name>.md`.
6262
2. Fill in the details according to the template instructions.
@@ -69,7 +69,7 @@ Follow the following steps to create a new proposal:
6969

7070
Solutions must be automated using one of the tools previously approved and listed [here](tools.md#approved-tools):
7171

72-
* Any new tool that participants want to enable will require an application using the Issue template [Tool application](todo.md).
72+
* Any new tool that participants want to enable will require an application using the [tool application template](./tool_template.md).
7373
* The tool will be analyzed by an independent committee consisting of members from the Rust open-source developers and AWS
7474
* A new tool application should clearly specify the differences to existing techniques and provide sufficient background
7575
of why this is needed.

doc/src/todo.md

Lines changed: 0 additions & 3 deletions
This file was deleted.
File renamed without changes.

doc/src/tools/kani.md

Lines changed: 59 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ Kani is designed to prove safety properties in your code as well as
55
the absence of some forms of undefined behavior. It uses model checking under the hood to ensure that
66
Rust programs adhere to user specified properties.
77

8-
You can find more information about how to install in [this section of the Kani book](https://model-checking.github.io/kani/install-guide.html).
8+
You can find more information about how to install in [the installation section of the Kani book](https://model-checking.github.io/kani/install-guide.html).
99

1010
## Usage
1111

@@ -27,7 +27,8 @@ fn harness() {
2727
let a = kani::any::<i32>();
2828
let b = kani::any::<i32>();
2929
let result = abs_diff(a, b);
30-
kani::assert(result >= 0, "Result should always be more than 0");}
30+
kani::assert(result >= 0, "Result should always be more than 0");
31+
}
3132
```
3233

3334
Running the command `cargo kani` in your cargo crate will give the result
@@ -46,29 +47,28 @@ Verification failed for - harness
4647
Complete - 0 successfully verified harnesses, 1 failures, 1 total.
4748
```
4849

50+
For a more detailed tutorial, you can refer to the [tutorial section of the Kani book](https://model-checking.github.io/kani/kani-tutorial.html).
4951

5052
## Using Kani to verify the Rust Standard Library
5153

52-
To aid the Rust Standard Library verification effort, Kani provides a sub-command out of the box to help you get started.
54+
Here is a short tutorial of how to use Kani to verify proofs for the standard library.
5355

54-
### Step 1
56+
### Step 1 - Add some proofs to your copy of the model-checking std
5557

56-
Modify your local copy of the Rust Standard Library by writing proofs for the functions/methods that you want to verify.
58+
Create a local copy of the [model-checking fork](https://github.com/model-checking/verify-rust-std) of the Rust Standard Library. The fork comes with Kani configured, so all you'll need to do is to call Kani's building-block APIs (such as
59+
`assert`, `assume`, `proof` and [function-contracts](https://github.com/model-checking/kani/blob/main/rfc/src/rfcs/0009-function-contracts.md) such as `modifies`, `requires` and `ensures`) directly.
5760

58-
For example, insert this short blob into your copy of the library. This blob imports the building-block APIs such as
59-
`assert`, `assume`, `proof` and [function-contracts](https://github.com/model-checking/kani/blob/main/rfc/src/rfcs/0009-function-contracts.md) such as `proof_for_contract` and `fake_function`.
6061

61-
``` rust
62-
#[cfg(kani)]
63-
kani_core::kani_lib!(core);
62+
For example, insert this module into an existing file in the core library, like `library/core/src/hint.rs` or `library/core/src/error.rs` in your copy of the library. This is just for the purpose of getting started, so you can insert in any existing file in the core library if you have other preferences.
6463

64+
``` rust
6565
#[cfg(kani)]
6666
#[unstable(feature = "kani", issue = "none")]
6767
pub mod verify {
6868
use crate::kani;
6969

7070
#[kani::proof]
71-
pub fn harness() {
71+
pub fn harness_introduction() {
7272
kani::assert(true, "yay");
7373
}
7474

@@ -84,21 +84,24 @@ pub mod verify {
8484
}
8585
```
8686

87-
### Step 2
87+
### Step 2 - Run the Kani verify-std subcommand
8888

89-
Run the following command in your local terminal:
89+
To aid the Rust Standard Library verification effort, Kani provides a sub-command out of the box to help you get started.
90+
Run the following command in your local terminal (Replace "/path/to/library" and "/path/to/target" with your local paths) from the verify repository root:
9091

91-
`kani verify-std -Z unstable-options "path/to/library" --target-dir "/path/to/target" -Z function-contracts -Z stubbing`.
92+
```
93+
kani verify-std -Z unstable-options "/path/to/library" --target-dir "/path/to/target" -Z function-contracts -Z mem-predicates
94+
```
9295

9396
The command `kani verify-std` is a sub-command of the `kani`. This specific sub-command is used to verify the Rust Standard Library with the following arguments.
9497

95-
- `"path/to/library"`: This argument specifies the path to the modified Rust Standard Library that was prepared earlier in the script.
96-
- `--target-dir "path/to/target"`: This optional argument sets the target directory where Kani will store its output and intermediate files.
98+
- `"path/to/library"`: This argument specifies the path to the modified Rust Standard Library that was prepared earlier in the script. For example, `./library` or `/home/ubuntu/verify-rust-std/library`
99+
- `--target-dir "path/to/target"`: This optional argument sets the target directory where Kani will store its output and intermediate files. For example, `/tmp` or `/tmp/verify-std`
97100

98-
Apart from these, you can use your regular `kani-args` such as `-Z function-contracts` and `-Z stubbing` depending on your verification needs.
101+
Apart from these, you can use your regular `kani-args` such as `-Z function-contracts`, `-Z stubbing` and `-Z mem-predicates` depending on your verification needs. If you run into a Kani error that says `Use of unstable feature`, add the corresponding feature with `-Z` to the command line.
99102
For more details on Kani's features, refer to [the features section in the Kani Book](https://model-checking.github.io/kani/reference/attributes.html)
100103

101-
### Step 3
104+
### Step 3 - Check verification result
102105

103106
After running the command, you can expect an output that looks like this:
104107

@@ -112,6 +115,44 @@ Verification Time: 0.017101772s
112115
Complete - 2 successfully verified harnesses, 0 failures, 2 total.
113116
```
114117

118+
### Running on a specific harness
119+
120+
You can specify a specific harness to be verified using the `--harness` flag.
121+
122+
For example, in your local copy of the verify repo, run the following command.
123+
124+
```
125+
kani verify-std --harness harness_introduction -Z unstable-options "./library" --target-dir "/tmp" -Z function-contracts -Z mem-predicates
126+
```
127+
128+
This gives you the verification result for just `harness_introduction` from the aforementioned blob.
129+
130+
```
131+
RESULTS:
132+
Check 1: verify::harness_introduction.assertion.1
133+
- Status: SUCCESS
134+
- Description: "yay"
135+
- Location: library/core/src/lib.rs:479:9 in function verify::harness_introduction
136+
137+
138+
SUMMARY:
139+
** 0 of 1 failed
140+
141+
VERIFICATION:- SUCCESSFUL
142+
Verification Time: 0.01885804s
143+
144+
Complete - 1 successfully verified harnesses, 0 failures, 1 total.
145+
```
146+
147+
Now you can write proof harnesses to verify specific functions in the library.
148+
The current convention is to keep proofs in the same module file of the verification target.
149+
To run Kani for an individual proof, use `--harness [harness_function_name]`.
150+
Note that Kani will batch run all proofs in the library folder if you do not supply the `--harness` flag.
151+
If Kani returns the error `no harnesses matched the harness filter`, you can give the full name of the harness.
152+
For example, to run the proof harness named `check_new` in `library/core/src/ptr/unique.rs`, use
153+
`--harness ptr::unique::verify::check_new`. To run all proofs in `unique.rs`, use `--harness ptr::unique::verify`.
154+
To find the full name of a harness, check the Kani output and find the line starting with `Checking harness [harness full name]`.
155+
115156
## More details
116157

117158
You can find more information about how to install and how you can customize your use of Kani in the

0 commit comments

Comments
 (0)