Guaranteeing Memory Safety in Rust

Rust
Nicholas Matsakis
Mozilla Research

What makes Rust different?
C++
Haskell
Java
ML
More Control More Safety
Rust: Control and safety

Why Mozilla?
Browsers need control.
Browsers need safety.
Servo: Next-generation
browser built in Rust.

What is control?
void example() {
vector<string> vector;
…
auto& elem = vector[0];
…
}
Stack and inline layout.
Lightweight references
Deterministic destruction
[0]
string
el…em
vector
data
length
capacity
[…]
[n]
…
‘H’
‘e’
…
Stack Heap
C++

Zero-cost abstraction
Ability to define abstractions that
optimize away to nothing.
vector data
length
cap.
[0]
[…]
data cap.
‘H’
‘e’
[…]
Not just memory layout:
- Static dispatch
- Template expansion
- … Java

What is safety?
void example() {
vector<string> vector;
…
auto& elem = vector[0];
vector.push_back(some_string);
cout << elem;
}
vector
data
length
capacity
[0]
…
[0]
[1]
elem
Aliasing: more than
one pointer to same
memory.
Dangling pointer: pointer
to freed memory.
C++
Mutating the vector
freed old contents.

What about GC?
No control.
Requires a runtime.
Insufficient to prevent related problems:
iterator invalidation, data races.

void foo(Foo &&f, …) {
vec.push_back(f);
}
C++
Gut it:
void foo(const Foo &f, …) {
use(f.bar);
}
Read it:
void foo(Foo &f, …) {
f.bar = …;
}
Write it:
void foo(unique_ptr<Foo> f, …) {
…
}
Keep it:

Definitely progress.
!
But definitely not safe:
!
- Iterator invalidation.
- Double moves.
- Pointers into stack or freed memory.
- Data races.
- … all that stuff I talked about before …
!
Ultimately, C++ mechanisms are unenforced.

The Rust Solution
Codify and enforce safe patterns
using the type system:
!
1. Always have a clear owner.
2. While iterating over a vector,
don’t change it.
3. …
!
No runtime required.

Credit where it is due
Rust borrows liberally from other great languages:
C++, Haskell, ML/Ocaml, Cyclone,
Erlang, Java, C#, …
Rust has an active, amazing community.
❤

Observation
Danger arises from…
Aliasing Mutation
Hides dependencies. Causes memory
to be freed.
{ auto& e = v[0]; … v.push_back(…); }

Three basic patterns
fn foo(v: T) {
…
}
Ownership
fn foo(v: &T) {
…
}
Shared borrow
fn foo(v: &mut T) {
…
}
Mutable borrow

Ownership!
!
n. The act, state, or right of possessing something.

Aliasing Mutation
Ownership (T)

vec
data
length
capacity
1
2
fn give() {
let mut vec = Vec::new();
vec.push(1);
vec.push(2);
take(vec);
…
}
fn take(vec: Vec<int>) {
// …
}
!
Take ownership
!
of a Vec<int>
!

Compiler enforces moves
fn give() {
vec.push(1);
vec.push(2);
take(vec);
vec.…
push(2);
}
fn take(vec: Vec<int>) {
// …
}
!
!
Error: ve! c has been moved
Prevents:
- use after free
- double moves
- …

Borrow!
!
v. To receive something with the promise of returning it.

Aliasing Mutation
Shared borrow (&T)

Aliasing Mutation
Mutable borrow (&mut T)

fn lender() {
vec.push(1);
vec.push(2);
use(&vec);
…
}
fn use(vec: &Vec<int>) {
// …
}
!
!
!
1
data
length
capacity
vec 2
vec
“Shared reference
to Vec<int>”
Loan out vec

fn dot_product(vec1: &Vec<int>, vec2: &Vec<int>)
elem1
elem2
sum
-> int {
let mut sum = 0;
for (elem1, elem2) in vec1.iter().zip(vec2.iter()) {
sum += (*elem1) * (*elem2);
}
return sum;
} walk down matching indices
elem1, elem2 are references into the vector
1
2
3
4
5
6
*
vec1 vec2

Why “shared” reference?
fn dot_product(vec1: &Vec<int>, vec2: &Vec<int>)
-> int
{…}
!
fn magnitude(vec: &Vec<int>) -> int {
sqrt(dot_product(vec, vec))
}
two shared references to the
same vector — OK!

Aliasing Mutation
Shared references are immutable:
fn use(vec: &Vec<int>) {
vec.push(3);
vec[1] += 2;
}
*
Error: cannot mutate shared reference
* Actually: mutation only in controlled circumstances

Mutable references
fn push_all(from: &Vec<int>, to: &mut Vec<int>) {
for elem in from.iter() {
to.push(*elem);
}
}
mutable reference to Vec<int>
push() is legal

Mutable references
1
2
3
to.push(*elem);
}
}
from
to
elem
1
2
3
…

What if from and to are equal?
1
2
3
from
to
elem
1
2
3
…
1
to.push(*elem);
}
} dangling pointer

fn push_all(from: &Vec<int>, to: &mut Vec<int>) {…}
!
fn caller() {
let mut vec = …;
push_all(&vec, &mut vec);
}
shared reference
Error: cannot have both shared
and mutable reference at same
time
A &mut T is the only way to access
the memory it points at

{
…
for i in range(0, vec.len()) {
let elem: &int = &vec[i];
…
vec.push(…);
}
…
vec.push(…);
}
Borrows restrict access to
the original path for their
duration.
Error: vec[i] is borrowed,
cannot mutate
OK. loan expired.
&
&mut
no writes, no moves
no access at all

Abstraction!
!
n. freedom from representational qualities in art.

Rust is an extensible language
• Zero-cost abstraction
• Rich libraries:
- Containers
- Memory management
- Parallelism
- …
• Ownership and borrowing
let libraries enforce safety.

fn example() {
let x: Rc<T> = Rc::new(…);
{
let y = x.clone();
let z = &*y;
…
} // runs destructor for y
} // runs destructor for x
x 1
[0]
y
2 1
…
z
Stack Heap

Borrowing and Rc
fn deref<‘a,T>(r: &’a Rc<T>) -> &’a T {
…
}
Given a borrowed reference
to an `Rc<T>`…
…return a reference to the
`T` inside with same extent
New reference can be thought of as a kind of sublease.
Returned reference cannot outlast the original.

fn example() -> &T {
let x: Rc<T> = Rc::new(…);
return &*x;
} // runs destructor for x
Error: extent of borrow
exceeds lifetime of `x`

Concurrency!
!
n. several computations executing simultaneously, and
potentially interacting with each other

Data race
✎
✎
✎
✎
Two unsynchronized threads
accessing same data!
where at least one writes.

Aliasing
Mutation
No ordering
Data race
Sound familiar?

data
length
capacity
fn parent() {
let (tx, rx) = channel();
spawn(proc() {…});
let m = rx.recv();
}
proc() {
let m = Vec::new();
…
tx.send(m);
}
rx
tx
tx
m

Shared read-only access!
(ownership, borrowing)

Arc<Vec<int>>
(ARC = Atomic Reference Count)
Owned, so no aliases. Vec<int>
&Vec<int>
ref_count
data
length
capacity
[0]
[1]
Shared reference, so
Vec<int> is immutable.

✎
✎
Locked mutable access!
(ownership, borrowing)

fn sync_inc(mutex: &Mutex<int>) {
let mut data = mutex.lock();
*data += 1;
}
Destructor releases lock
Yields a mutable reference to data
Destructor runs here

And beyond…
Parallelism is an area of active development.
!
Either already have or have plans for:
- Atomic primitives
- Non-blocking queues
- Concurrent hashtables
- Lightweight thread pools
- Futures
- CILK-style fork-join concurrency
- etc.
Always data-race free

Parallel!
!
adj. occurring or existing at the same time

Concurrent vs parallel
Blocks
Concurrent threads Parallel jobs

fn qsort(vec: &mut [int]) {
let pivot = vec[random(vec.len())];
let mid = vec.partition(vec, pivot);
let (less, greater) = vec.mut_split_at(mid);
qsort(less);
qsort(greater);
}
let vec: &mut [int] = …;
[0] [1] [2] [3] […] [n]
less greater

fn parallel_qsort(vec: &mut [int]) {
let pivot = vec[random(vec.len())];
let mid = vec.partition(vec, pivot);
let (less, greater) = vec.mut_split(mid);
parallel::do(&[
|| parallel_qsort(less),
|| parallel_qsort(greater)
]);
}
let vec: &mut [int] = …;
[0] [1] [2] [3] […] [n]
less greater

Unsafe!
!
adj. not safe; hazardous

Safe abstractions
fn something_safe(…) {
!
unsafe {
!
…
!
}
!
}
Validates input, etc.
Trust me.
• Uninitialized memory
• Interfacing with C code
• Building parallel abstractions like ARC
• …

Status of Rust
“Rapidly stabilizing.”!
!
!
Goal for 1.0:
- Stable syntax, core type system
- Minimal set of core libraries

Conclusions
• Rust gives control without compromising safety:
• Zero-cost abstractions
• Zero-cost safety
• Guarantees beyond dangling pointers:
• Iterator invalidation in a broader sense
• Data race freedom

Guaranteeing Memory Safety in Rust

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Guaranteeing Memory Safety in Rust (20)

Recently uploaded (20)

Guaranteeing Memory Safety in Rust