forked from verifast/verifast
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Rust] share_full takes atomic_mask(MaskTop); verifying atomic.rs (ve…
…rifast#692) The share_full component of the type interpretation now takes atomic_mask(MaskTop) instead of atomic_mask(Nlft). This enables verifying sync::atomic, and in particular that no mixed-size conflicting atomic accesses occur. Also: - The precondition of share_full now additionally asserts ref_origin(l) == l. - Rust has no subobject provenance. - Started work on atomic.rs: Verified AtomicBool::from_ptr and AtomicBool::store - If p is a &UnsafeCell, p.get() calls are translated to ref_origin(p) calls.
- Loading branch information
Showing
25 changed files
with
4,241 additions
and
137 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# Verifying compliance with Rust's pointer aliasing rules | ||
|
||
Breaking [Rust's pointer aliasing | ||
rules](https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.alias) | ||
or mutating [immutable | ||
bytes](https://doc.rust-lang.org/reference/behavior-considered-undefined.html#r-undefined.immutable) | ||
is undefined behavior. VeriFast currently verifies (only) the latter. | ||
|
||
In particular, it verifies that the memory pointed to by a shared reference, | ||
except for the memory inside an `UnsafeCell`, is not mutated while the shared | ||
reference is active. First of all, shared reference creation is treated like the | ||
creation of a new pointer value, with the same address but a different | ||
[provenance](https://doc.rust-lang.org/std/ptr/index.html#provenance) from the | ||
original pointer. Points-to resources for the original pointer cannot be used | ||
for accesses through the new shared reference. | ||
|
||
VeriFast requires, at creation of a shared reference, that the user transfer a | ||
fraction greater than 0 and less than 1 of the points-to resources for the | ||
original place to the new shared reference. These resources are transferred back | ||
to the original reference when the shared reference is *ended* (and only then); | ||
from that point on, the shared reference is no longer usable. | ||
|
||
Specifically, a shared reference creation expression `&E` is treated like a call | ||
of function `create_ref` in | ||
[`aliasing.rsspec`](https://github.com/verifast/verifast/blob/master/bin/rust/aliasing.rsspec), | ||
which is part of the VeriFast for Rust prelude. This function requires that a | ||
shared reference value has been *precreated* using lemma `precreate_ref` | ||
declared in the same file. Furthermore, it requires that the new reference has | ||
been *initialized*. | ||
|
||
Memory inside an `UnsafeCell` is exempted from this process; the points-to | ||
resources for that memory are never transferred. This means that a shared | ||
reference to an `UnsafeCell` does not directly provide access to the memory | ||
behind the `UnsafeCell`. To access the memory, the developer has to call | ||
`UnsafeCell::get`. VeriFast treats calls of this method like calls of logical | ||
function `ref_origin` (also declared in `aliasing.rsspec`). Therefore, if a | ||
struct S has a field f of type `UnsafeCell<T>` inside, it is important for | ||
`<S>.share(k, t, l)` to (directly or indirectly, e.g. via a nonatomic borrow), | ||
assert points-to resources for `ref_origin(&(*l).f)`. See, for example, | ||
[cell.rs](https://github.com/verifast/verifast/blob/master/tests/rust/safe_abstraction/cell.rs) | ||
and | ||
[mutex.rs](https://github.com/verifast/verifast/blob/master/tests/rust/safe_abstraction/mutex.rs). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.