reorganized active discussions

Author: avadacatavra

active_discussion.md

@@ -0,0 +1 @@
+# Areas of active discussion

active_discussion/aliasing.md

@@ -0,0 +1,18 @@
+# Aliasing and memory model
+
+## Brief Summary
+
+Rust's borrow checker enforces some particular aliasing
+requirements. For example, an `&u32` reference is always guaranteed to
+be valid (dereferenceable) and immutable while it is in active
+use. Similarly, an `&mut` reference cannot alias any other active
+reference. It is less clear how those invariants translate to unsafe
+code that is using raw pointers.
+
+## See also
+
+- ACA model https://github.com/nikomatsakis/rust-memory-model/issues/26
+- Capability-based model https://github.com/nikomatsakis/rust-memory-model/issues/28
+- A formal C memory model supporting integer-pointer casts https://github.com/nikomatsakis/rust-memory-model/issues/30
+- Promising semantics for relaxed-memory concurrency https://github.com/nikomatsakis/rust-memory-model/issues/32
+- Tootsie Pop model https://github.com/nikomatsakis/rust-memory-model/issues/21

active_discussion/crypto_concerns.md

@@ -0,0 +1,4 @@
+# Cryptographic concerns
+
+There are a number of concerns that arise when writing cryptographic
+code. This chapter summarizes some of them.

active_discussion/crypto_concerns/constant_time_code.md

@@ -0,0 +1,5 @@
+# Constant time code
+
+It is often important to be able to turn off optimizations and
+guarantee that code executes in constant time to prevent side-channel
+attacks based on timing.

active_discussion/crypto_concerns/keeping_secrets.md

@@ -0,0 +1,11 @@
+# Keeping secrets
+
+When storing cryptographic keys, crypto code wants to be sure that the
+compiler will not insert loads or stores that were not present in the
+source. Moreover, it wants to be able to zero memory and know that no
+bits from that memory "escape" into registers etc.
+
+## See also
+
+- https://internals.rust-lang.org/t/volatile-and-sensitive-memory/3188
+- https://github.com/nikomatsakis/rust-memory-model/issues/16

active_discussion/representation.md

@@ -0,0 +1,14 @@
+# Data structure representation
+
+In general, Rust makes few guarantees about memory layout, unless you
+define your structs as `#[repr(rust)]`. But there are some things that
+we do guarantee. Let's write about them.
+
+TODO:
+
+- Find and link to the various RFCs
+- Enumerate things that we *might* in fact guarantee, even for non-C types:
+  - e.g., `&T` and `Option<&T>` are both pointer sized
+  - size of `extern fn` etc (at least on some platforms)?
+  - For which `T` is `None` represented as a "null pointer" etc?
+    - (Which "niche" optimizations can we rely on)

active_discussion/stable_addresses.md

@@ -0,0 +1,25 @@
+# Stable addresses
+
+Clearly, if you have a `&T` reference, the actual pointer address of
+that memory must remain valid while **that reference** is in active
+use. But how stable are the memory addresses of local variables in
+between borrows? Consider:
+
+```rust
+let x = 22;
+foo(&x);
+foo(&x);
+
+fn foo(y: &usize) { .. }
+```
+
+Is `foo` guaranteed to be given the same pointer each time? Note that
+safe code can observe the pointer value by doing `y as *const usize as
+usize`. If, however, the answer is no, that is helpful to the compiler
+since it can spill `x` only while it is borrowed but otherwise simply
+store `x` in a register.
+
+**Range of possible answers:**
+
+- local variables have stable addresses (de facto true today)
+- local variables have stable addresses while borrowed, but may change betwen borrows (would be nice)

active_discussion/storage_liveness.md

@@ -0,0 +1,13 @@
+# Storage liveness
+
+If you move out from a variable, can you still use the underlying stack space?
+
+```rust
+{
+  let mut x: Vec<u32> = ....;
+  let p: *mut Vec<u32> = &mut x;
+  drop(x); // compiler can see `x` is uninitialized
+        
+  // what happens if you use `p` here?
+} // StorageDead(x)
+```

active_discussion/uninhabited_types.md

@@ -0,0 +1,3 @@
+# Uninhabited types like `!` and exhaustiveness
+
+TBD

active_discussion/uninitialized_memory.md

@@ -0,0 +1,3 @@
+# Uninitialized memory
+
+TBD

active_discussion/unions.md

@@ -0,0 +1,3 @@
+# Unions
+
+TBD

projects.md

@@ -0,0 +1,13 @@
+# Projects related to Unsafe Code Guidelines
+
+## Blogs and other related discussions
+* [Stacked Borrows: An Aliasing Model for Rust](https://www.ralfj.de/blog/2018/08/07/stacked-borrows.html)
+* [Two Kinds of Invariants: Safety and Validity](https://www.ralfj.de/blog/2018/08/22/two-kinds-of-invariants.html)
+* [An alias-based formulation of the borrow checker](http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based-formulation-of-the-borrow-checker/)
+
+
+## Code and Tools
+
+Any code projects related to the effort should be included here:
+* [Miri](https://github.com/solson/miri)
+* [unsafe-unicorn](https://github.com/avadacatavra/unsafe-unicorn): naive text-based analysis for unsafe usage