►
Description
Writing Linux Kernel Modules in Safe Rust - Geoffrey Thomas, Two Sigma Investments & Alex Gaynor, Alloy
With 65% of recent Linux kernel vulnerabilities being the result of memory unsafety (buffer overflows, pointers used after being freed, etc.) and not logic errors, both kernel developers and downstream users have wondered whether it's possible to use a safer language than C for kernel development. This talk will explore the presenters' work building a framework for writing kernel modules in Rust and accessing kernel APIs in safe Rust. In particular, the talk will discuss some of the challenges of building binary-compatible kernel modules in Rust, techniques for working with existing C code, and how to design safe bindings over raw kernel APIs. It will also discuss advantages and difficulties for integrating Rust in upstream kernel development and possible directions the upstream kernel community could go.
A
A
B
So
vulnerabilities
due
to
memory
corruption
are
extremely
common
and
extremely
preventable.
So
a
definition
of
memory
unsafety
is
sort
of
the
property
of
a
programming
language
to
without
programmers
going
out
of
their
way
to
allow
them
allow
programmers
to
introduce
use
after
free
double
free,
Wildtree
overflows
under
flows,
wild
pointers,
use
of
uninitialized
memory
and
data
races,
often
leading
to
all
of
the
above.
So
some
statistics
about
the
prevalence,
memory
and
safety.
B
So
approximately
49
percent
of
the
Chrome
security
vulnerabilities
in
2019
had
memory
unsafety
as
a
root
cause
72%
of
the
Firefox
vulnerabilities
in
2019
81
percent
of
0
days
in
the
wild
since
2014,
as
tracked
by
Google's
project
zero
had
memory
unsafety
as
a
root
cause,
but
these
are
all
silly
user
space
problems.
Kernel
programmers
are
very
serious
and
would
not
introduce
the
same
sorts
of
bugs
into
their
programs.
So
surely
the
numbers
are
more
promising
about
kernels
tastes.
B
88
percent
of
mac,
OS
kernel
vulnerabilities
in
the
1014
series
had
memory.
Corruption,
Microsoft
doesn't
release
quite
as
granular
statistics,
but
they've
said
as
a
whole,
since
2006
estimated
70%
of
vulnerabilities
across
all
of
their
products
head
memory
on
safety
as
a
root
cause
and
I
would
bet
almost
anything.
The
kernel
is
higher
than
other
products,
65%
of
kernel
CVEs
that
made
their
way
into
a
bun
two
security
notifications.
In
the
six
months
before
we
perform
these
slides
were
memory
on
safety
65%
of
all
Android
TVs.
This
is
inclusive
of
both
kernel
and
user.
B
Space
had
memory
on
safety,
Cisco
lurk
at
the
day
we
produced
the
slide
was
claimed
225
things
that
looked
like
ka
Center
km.
San
a
paper
released
two
or
three
weeks
ago
that
performed
use
after
free
static
analysis
on
a
bunch
of
kernel.
Data
structures,
particularly
focused
on
concurrency,
had
hundreds
of
findings.
These
vulnerabilities
have
the
same
root.
Cause
c
and
c++
enables
programmers
to
trivially
introduce
critical
vulnerabilities.
B
These
vulnerabilities
have
outcomes
like
surveilling
dissidents,
advocating
for
human
rights
in
the
middle
east,
taking
down
entire
hospital
systems
and
even
surveilling
nutritionists
in
mexico
working
on
soda
taxes.
That
is
a
for
real
thing.
Where
memory
corruption
was
used
to
surveil,
these
people,
surely
there's
a
better
way
so
we're.
A
Looking
at
c
and
c++
in
kernel
space,
because
we've
got
needs
for
high
performance,
we've
got
needs
to
talk
to
the
hardware,
etc.
We
probably
don't
want
to
be
using
something
like
Python
or
Java.
What
could
we
do?
We
could
stick
with
C.
We
could
try
hardening
C
there's
a
very
good
talk
last
year
about
make
you
see.
Better
people
have
talked
about
a
few
approaches
so
far.
One
of
the
things
we've
picked
up
from
this
is
that
all
of
these
are
fundamentally
mitigations.
They
are,
we
will
have
bugs.
A
We
will
not
keep
up
with
their
bugs.
Aslr
is
a
workaround
to
perfect,
make
the
bugs
harder,
but
not
impossible
to
exploit
several
fees
like
stack
leak
have
overhead.
Several.
These
things
like
sparse
and
Coverity
doing
static
analysis
have
been
used,
but,
unlike
at
the
end
of
the
day,
they
are
not
stemming
the
tide
we
are
still
having
hundreds
and
hundreds
of
vulnerabilities,
so
hardening
see,
is
a
admirable
goal,
but
it
is
not
quite
enough
what
about
isolation?
A
What
if
we
say,
let's
run
parts
of
the
kernel
in
you
know
we
could
run
them
in
web
assembly.
We
used
data
sandbox
name.
We
could
write
interesting
things
in
EVP
F.
We
could
use
Hardware
support,
we
could
go
microkernel
which
again
has
the
same
sort
of
overhead
issue
of
how
long
does
it
take
to
execute
code?
That
is
in
isolation,
and
can
you
even
use
isolation
before
things
like?
Can
my
scheduler
be
isolated?
Can
we
you
know?
How
would
I
do
that?
A
A
A
Why
aren't
we
actually
writing
Linux
in
Java,
which
is
not
an
argument
for
Java,
but
what
is
going
on
with
C
like
what
should
we
be
doing
here
and
if
you
go
back
to
2004
well
in
his
head,
there
was
a
proposal
about,
should
we
write
Linux
in
C++,
and
we
can
talk
about.
You
know
why
C++
does
not
actually
solve
any
of
memory
safety
problems,
but
without
you
know
quite
endorsing
the
approach
here.
I
think
that
the
ideas
that
Lenny
mentioned
are
very
important,
which
is
C++,
brings
things
like
exception
handling.
A
It
brings
things
like
memory
allocations
and
it
brings
things
like
a
particular
approach
to
Africa
orientation,
which
is
not
quite
suitable
for
kernel
space.
So
what
do
we
want
out
of
a
potential
language
here?
We
want
memory
safety.
Of
course
we
want
exception
handling.
If
it
doesn't
do
unwinding,
we
want
oo
without
the
overhead
things
like
diamond
dependencies,
multiple
inheritance,
we
don't
want
hidden
memory
allocations.
A
Several
promising
languages
have
garbage
collectors
or
runtimes
which
make
them
unsuitable,
and
we
also
want
very
performant
FFI
to
see
if
we
have
any
hope
of
integrating
with
the
existing
large
body
of
C
code
and
so
there's
a
handful
of
very
good
languages,
Haskell
Goudy,
ADA,
etc,
which
just
happened
not
to
be
what
we
want
for
this
purpose.
One
thing
I
want
to
mention
briefly
is
ADA
people
mention
in
the
context
of
a
save
compiled
language
and
I,
think
it's
unfamiliar
to
many
people.
A
So
the
real
issue
with
it
is
that
within
ada
itself,
there
is
no
sort
of
safe,
dynamic
memory
management.
It's
designed
for
use
cases
where
you
can
say
I
statically
know
exactly
what
my
tasks
are
and
what
memory
I
want.
I
can
do
that
compile
time.
There
is
support
for
dynamic
allocation,
but
as
far
as
I
know,
the
deallocate
operator
is
unsafe.
You
were
expected
to
track
lifetimes
on
your
own,
which
brings
back
use
after
free,
etc.
A
The
standard
solution
for
things
that
are
not
embedded
is
to
use
a
library
that
does
garbage
collection,
but
we
probably
do
not
want
to
garbage
collection.
So
that
brings
us
to
rust.
Rust
is
a
compiled
language
intended
for
systems,
programming,
Mozilla
research
or
some
individuals
resume
relation
originally
created
as
a
better
slash,
more
secure
implication,
language
for
Firefox,
which
is
a
very
large
C++
code
base.
It
now
has
many
production
users
and
relevantly
for
us,
it
is
backed
by
LVM
in
userspace.
A
It
uses
the
system
linker
in
Lib
C,
it
generates,
auto
files
uses
the
platform
calling
convention
etc.
Basically,
it
is
a
language
that
sort
of
operates.
The
way
folks
who
are
working
on
C
would
expect
it
to
work,
and
so
that
makes
it
suitable
for
incremental
rewrites.
You
can
use
rust
to
generate
a
dot
o
that
you
can
very
directly
call
from
C
and
vice
versa.
If
you
were
familiar
with
rust
before
1.0,
you
might
remember
that
it
had
a
garbage
collector
that
it
had
a
threading
runtime
built
in
it
had
Sigma,
2,
stacks,
etc.
A
All
of
this
was
removed
during
rust
development
before
100,
and
so
now
it's
a
very
sort
of
tight
C
compatible
language
which
makes
it
appealing.
So,
let's
take
a
look
at
what
Russ
does
for
memory
safety
I'm
going
very
fast
if
you
are
interested
in
working
in
rust,
I
strongly
recommend
the
official
book
on
their
website.
I
don't
have
enough
time
to
go
and
cover
it
in
huge
amounts
of
detail,
so
this
will
be
fast.
This
is
a
hello
world
very
simple
program.
The
syntax
should
be
largely
familiar
to
C
programmers.
A
A
Why
it's
a
macro
is
a
little
bit
out
of
scope
for
this
talk,
but
basically,
since
print
line
wants
to
take
an
arbitrary
number
of
parameters
with
arbitrary
numbers,
types
has
to
do
some
stuff
at
compile
time
to
handle
variable
arguments
in
a
safe
way,
and
so,
if
you
see
the
exclamation
point
all
it
means
is,
it
is
a
macro
that
doesn't
quite
follow.
It's
not
a
functions
on
quite
follow.
Syntax,
that's
all
it's
pretty
rare,
so
variables
and
rust
are
constant
by
default.
So
this
program
is
an
error.
A
It
will
say
you
tried
to
modify
X,
which
is
not
mutable,
so
you
can
just
modify
it,
make
it
mutable,
and
this
will
run
you're
allowed
to
leave
a
variable,
uninitialized
and
rust,
but
you
have
to
assign
something
to
that
variable
before
you
use
it.
So,
unlike
and
C,
you
can't
have
accidental
use
of
uninitialized
variables
in
this
case
the
first
line
is
perfectly
legitimate,
but
the
rest
will
notice
by
the
second
line.
This
variable
was
potentially
I
initialized.
That
is
an
error.
A
That
is
not
just
a
warning,
and
also
you
get
this
error
message
which
says
that
rust
wants
to,
or
print
line
rather
wants
to
borrow
this
variable
X.
So
we'll
talk
about
rust
reference
system
in
a
tiny
bit
and
how
what
Baro
means
in
that
context,
a
few
more
bits
of
syntax
rust
has
structures
just
like
C
syntax
is
a
little
bit
different,
but
should
be
pretty
familiar.
Rust
lets
you
put
methods
on
structures
which
is
probably
starting
to
remind
you
of
c++,
and
you
should
not
take
this
as
it
being
like
c++.
A
This
object
orientation,
it
does
not
have
inheritance,
encourages
you
to
use
composition,
which
is
good
for
us.
It
avoids
multiple
inheritance,
virtual
functions
down
casting
all
sorts
of
weird
runtime
stuff.
You
don't
have
the
question
about
is
a
square,
a
subclass
of
a
rectangle
or
vice-versa.
You
try
to
avoid
that
and
a
couple
of
syntax
notes
here
that
ampersand
in
self
means
reference
which
we'll
get
to
in
a
little
bit.
For
now.
You
should
just
read
that
as
a
con
star,
except
your
guarantee,
that
is
valid,
also
note
the
arrow
for
return
value.
A
And
finally,
if
you
end
a
function
with
an
expression
and
no
semicolon,
it
just
returns
that
value
one
of
the
things
about
Brussels.
It
was
designed
with
some
good
amount
of
influence
from
functional
programming
communities.
It
isn't
imperative
language,
it
is
a
systems
language,
but
you
can
see
that
influence
here.
Rust
also
does
have
public
and
private.
We
don't
have
time
to
cover
that
here,
but
you
can
definitely
say:
I
am
making
a
safe
abstraction
and
I'm
encapsulating
sort
of
what
happens
underneath.
A
So
you
get
the
good
parts
of
oo,
which
is
a
encapsulation
abstraction
sort
of
putting
things
where
they
belong,
but
you
stay
away
from
the
weird
parts.
The
way
rust
gets
you
polymorphism
is
what's
called
traits.
A
trait
is
a
set
of
methods
that
you
can
implement
on
a
structure.
It's
like
an
interface
or
a
protocol
in
some
other
languages
or
for
Colonel
folks.
You
would
recognize
this
as
similar
to
an
operation
structure.
You
can
put
default,
implementations
and
traits
you
can
have
traits
that
depend
on
other
traits
like
you
can
only
implement
shape.
A
If
you
also
implement
you
know
surface
or
something
I
don't
know,
but
it
won't
like.
You
have
problems
like
method,
name
conflicts.
If
I
had
both
this
area
function,
I'm
defining
here
and
the
one
for
the
previous
slide
and
I
had
like
my
circle,
dot
area,
it
would
actually
say
you
know,
that's
that's
ambiguous,
which
one
do
you
want
me
to
call?
So
it
is
not
inheritance,
it
is
a
collection
of
methods.
It
is,
you
know
a
lot
more
obvious.
What's
going
on,
you
can
do
generic
slash
polymorphism
in
two
ways.
A
One
is
you
can
make
it
generic
over
anything
that
implements
a
trait,
and
this
is
expanded
at
compile
time
for
each
time
that
uses
it.
There's
no
runtime
dynamic
stuff!
That's
called
here.
If
I
take
this
function,
I
call
it
on
a
circle
and
I
call
it
on
a
rectangle
there'll,
be
two
copies
of
this
code
in
the
final
binary.
A
The
other
thing
I
can
do
is
I
can
do
a
dynamic
call
where
I
say
I
actually
do
want
to
take
a
trait
object,
which
is
basically
a
fat
pointer
with
both
the
object
itself
and
the
vtable.
For
what
methods
I
want-
and
so
this
will
compile
into
a
single
function
that
does
a
dispatch
at
runtime
on
the
type
of
shape
and
you'll,
see
the
dine
keyword
and
that
sort
of
a
general
pattern
in
rust.
A
If
there's
some
complexity
happening
at
runtime,
you
have
to
specifically
opt
into
it,
usually
there's
some
syntax
calling
out
that
you're
doing
something
special,
and
so
you
can
also
doing
a
lot
of
neat
things
like
a
pie.
Time
like
we
saw
on
the
last
slide
and
they
compiled
out
with
rust
as
LTO
and
often
just
optimized
out.
We
will
also
see
the
borrowed
checker
in
a
little
bit,
which
is
also
all
at
compile
time.
A
Rusted
C++
both
have
a
term
for
this,
which
is
zero
cost
abstractions,
which
means
you
only
pay
for
things
you
want
to
pay
for,
and
the
language
is
not
imposing
things
on
you
and
that
is
I.
Think
one
of
the
things
that's
absolutely
critical.
If
you're
thinking
what
language
should
I
use
for,
something
like
a
kernel,
rust
also
has
enums.
The
first
part
of
this
should
look
familiar
from
C.
An
enum
is
a
unique
type.
It
is
not
just
an
alias
for
the
integer
and
it
is
impossible
and
safe
rust
to
construct
an
enum.
A
That
is
not
one
of
these
values,
so
this
match
statement
at
the
bottom
is
in
fact
exhaustive,
even
though
it
doesn't
have
a
default
case,
because
you
know
any
object
of
type
go
over.
Commit
policy
has
to
be
one
of
those
three
values:
enums
can
carry
data,
so
this
probably
looks
a
little
bit
less
familiar
from
C.
If
you
have
a
functional
programming
background,
you
might
recognize
this
as
a
some
type.
A
The
underlying
storage
format
is
an
integer
discriminant
saying
what
is
what
type,
what
variant
of
enum
it
is
followed
by
the
data.
So
it's
a
tagged
Union,
it's
not
quite
like
us
to
Union
and
access
to
the
data
is
safe
in
that
the
only
way
you
can
get
a
reference
to
a
member
of
a
particular
variant
is,
if
you
have
actually
checked
that
it
belongs
to
this
variant.
A
So
in
this
match
statement,
I
cannot
access
host
unless
it's
actually
of
type
of
subtype
address
colon
colon
IP,
and
there
are
very
two
common
enums
and
rust
option
and
result
which
are
defined
in
the
standard
library
option
is
what
you'd
use
for
optional
or
nullable
values
and
result
is
how
you
do
error
handling
you
either
have
a
successful
value
of
type
T
or
an
error
object
of
type
e,
an
error
object
can
be,
or
whatever
sort
of
thing
makes
sense.
Maybe
it's
an
enum
that
has
various
types
of
errors.
A
It's
common
for
libraries
to
type
def
a
result,
type
with
their
particular
error
object
and
then
there's
one
more
syntax
construct.
If
yeah
it's
not
here,
if
flat,
which
is
the
same
sort
of
thing
as
match
combined
with,
if
the
only
way
you
can
get
at
a
action,
a
useable
object
of
type
T
out
of
an
option
is
if
it
is
in
fact
of
this
variant
called
some.
A
So
at
the
end
of
the
day,
the
representation
memory
is
just
like
an
SI,
but
at
the
syntax
level,
there's
no
way
to
accidentally
mess
this
up
and
rust
doesn't
have
exceptions
that
you
throw
in
catch,
because
they've
got
pretty
good
syntax
for
handling
options
and
results.
The
recommended
way
to
handle
things
that
could
potentially
fail
is
to
return
a
result
or
an
option.
Have
the
caller
check
it,
which
again
is
pretty
similar
to
how
the
kernel
does
error
handling?
You
return
a
pointer
that
has
one
of
the
magical
error.
A
Values
is
a
negative
value
or
something,
and
you
have
the
caller
check
it,
and
so
there's
no
exception.
Throwing
in
the
kernel
so
very
ship,
you
should
feel
very
similar
with
the
notable
advantage
of
it
is
statically,
checked
sort
of
at
compile
time
that
you
were
not
accidentally
taking
negative
Ino
ma'am
and
using
that
as
a
pointer
or
whatever,
and
there's
one
even
nicer
bit
of
syntax,
which
is
the
question
mark
operator.
Some
of
the
left
question
mark
expands
to
one
of
two
possible
things.
A
If
it's
okay,
then,
if
I
see,
if
I
have
an
object
of
variate,
okay
and
I
put
the
question
mark
it
just
unwraps
it.
If
I
have
an
object
of
variant,
error
and
I
put
the
question
mark,
it
expands
syntactically,
it's
basically
syntax
sugar
for
a
return
from
this
function.
Converting
the
error
object,
if
necessary,
to
the
error
of
this
type.
A
So
I
can
make
code
that
reads
very
straightforwardly
like
code
on
the
right,
well,
I,
say
I'm,
going
to
open
this
thing
that
might
fail
I'm
going
to
read
it
that
might
fail
and
get
a
parse
it
that
might
fail
at
the
end.
If
that
all
worked,
I
will
return
another
result
type
with
my
data
and
a
straight
line
code.
A
There's
no
throwing
catch
behind
the
scenes,
it's
very
clear
what
this
is
expanding
to
the
compiler
isn't
doing
anything
magical,
and
so,
if
I
ever
wanted
to
handle
one
of
these
cases
myself
with
the
match
statement,
I
could
just
do
that.
So
nothing
implicit.
It's
just
like
if
I
put
a
bunch
of
if
statements
and
see
but
I,
don't
have
to
write
that
for
genuinely
exceptional
conditions
like
division
by
zero
or
indexing
out
of
bounds.
So
one
over
zero
or
three
four
five
sub
ten
will
do
would
rust
cause
a
panic.
A
That's
usually
implemented
with
the
same
infrastructure
as
CFLs
plus
exception
throwing
and
that
it
unwinds
the
stack
it
can
be
caught,
but
it
is
strongly
not
recommended
to
use
it
for
error
handling.
It's
mostly
for
things
like
I
have
a
web
server,
and
one
of
the
threads
has
panicked,
but
I
want
the
rest
of
the
web
server
to
continue
running
if
possible,
or
in
kernel
and
I.
A
Have
you
know
one
kernel
thread
or
sis
call
that
hit
a
bug
and
I
would
like
to
kill
that
user
space
process,
but
I
would
like
to
not
panic
the
entire
kernel
and
so
again
sort
of
similar
philosophy
and
how
you
design
things.
If
you
have
something
that
might
fail
rust,
basically,
always
you
know,
as
a
convention,
libraries
will
give
you
a
way
to
do
that
without
panicking,
and
so,
if
you
do
get
instead
of
the
index
operator,
it
will
give
you
an
option,
and
so,
in
this
case
three
four
five
ten
will
just
return.
A
You
none
and
then
you
can
always
do
an
explicit
panic
with
the
panic
macro
and
so
yeah.
If
you
haven't
noticed
the
thing
I'm
trying
to
sell
you
on
here
is
the
way
you
rust
things
about
things
like
how
do
I
do
oo
or
how
do
I
do
error
handling
turns
out
to
be
very
similar
to
the
way
the
Linux
kernel
has
also
decided.
What
is
the
best
way
to
handle
object
orientation?
How
do
I
put
a
bunch
of
methods
on
an
inode,
or
you
know?
C
A
A
So
it's
got
a
borrow
checker
and
when
you
take
a
reference
with
variable
keeps
track
of
how
long
you
are
borrowing
that
variable
is
syntactically
lexically
and
you
cannot
borrow
a
variable
for
a
longer
than
it
actually
exists.
So
imagine
a
for
loop
like
this
for
I
and
one
through
five
y
equals
reference
to
I
and
then
I
try
to
print
line
Y
at
the
end
of
that
for
loop.
A
This
would
be
a
very
easy
mistake
to
make
in
a
language
like
C,
in
that
you
could
have
something
and
just
have
it
escape
the
stack
from
beyond,
where
it
lived
and
in
a
language
with
garbage,
collector,
ref,
counting,
imagine,
Python
or
Java
the
way
we'd
handle.
This
is
by
just
doing
an
Inc
graph
incrementing
the
reference
count
on
high
and
just
keeping
that
alive
until
the
end
of
the
function,
but
rust
does
not
want
garbage
collections,
sort
of
I,
don't
know
when
this
objects
being
released.
A
You
want
to
know
statically
what
is
happening
to
your
memory
usage,
and
so
the
compiler
is
tracking,
where
each
reference
comes
from
and
it
gives
you
an
error.
Yeah
absolutely
do
quite
clear
error
saying
you
know
apt.
This
particular
location
I
does
not
live
long
enough
because
it
was
borrowed
from
over
here
and
it
was
dropped
at
this
curly
brace.
A
If
you
want
this
to
you
work,
one
thing
you
could
do
is
use
the
standard
library
type
RC,
which
is
a
ref
counting
pointer.
That
is
an
opt-in.
I
would
like
to
just
allocate
this
on
the
heap
and
permit
the
ref
every
time.
I
make
another
pointer
to
it
and
ridi
allocate
it
once
the
ref
count
drops
to
zero,
and
so
in
terms
of
overhead
is
like
any
ref
count
under
garbage
collected
language,
but
it
has
the
advantage
that
you
only
pay
for
that
cost.
A
If
you
actually
want
it,
you
actually
say
this
is
what
I
want
and
like
variables.
References
are
also
constant
by
default.
If
I
try
to
modify
something
through
a
ampersand
reference
instead
of
any
ampersand
mute
reference,
it
will
say
you
can't
do
that
and
gives
me
an
error.
Tell
me
what
I
should
change
and
Russ
does
something
more
interesting
with
mutable
references,
which
is
that
you
can't
have
more
than
one
mutable
reference.
At
the
same
time,
you
can't
have
a
mutable
reference
and
a
constant
reference
at
the
same
time.
A
Basically,
you
can
think
of
this
as
a
compile
time.
Reader/Writer
lock,
you
can
have
multiple
readers,
but
you
can
only
have
one
writer
and
that
writer
that
mutable
reference
is
temporarily
borrowing
all
access
to
that
variable
for
as
long
as
it
exists.
So
really
the
way
to
think
of
and
well
like
in
a
next
slide,
I
think
about
how
you
would
get
around
this.
A
If
you
do
have
ways
to
safely
modify
a
variable
concurrently,
is
that
you
should
think
about
ampersand
mute
as
a
unique
reference,
and
you
should
think
about
the
ampersand
as
a
shared
reference.
If
you
have
a
piece
of
data
with
ampersand
mute,
you
know
that
nobody
is
aliasing
it.
Nobody
else
has
a
reference
to
it,
etc.
If
you're
a
piece
of
day
with
a
murse-
and
you
know
you
don't
know
that
no
one
else
is
aliasing
it,
but
you
do
know
that
it
is
living
for
as
long
as
you
have
this
reference
around.
A
So
you
might
be
thinking
at
this
point.
This
all
seems
very
restrictive
or
what,
if
I,
do
want
to
modify
something
concurrently?
Obviously,
if
I
followed
that
rule
just
there
with
the
ampersand
represent
mute,
I
won't
have
any
use
after
phrase.
I
won't
have
any
race
conditions
but
like
there
are
plenty
of
cases
where
two
people
have
mutable
pointers
the
same
data
and
they
successfully
avoid
a
corrupting
memory.
How
do
I
do
that,
and
so
that's
great
as
long
as
you
do
it
in
a
controlled
way.
A
Russ
lets
you
bypass
all
of
these
rules
as
long
as
you
use
the
keyword
unsafe.
So
what
you
should
do
is
create
safe
abstractions,
where
you
say:
I've
got
a
wrapper
type
or
the
implementation
uses
the
keyword
unsafe
and
it's
checking
in
some
way
using
the
type
system
using
syntax,
etc
that
what
I'm
doing
is
safe
and
then
a
test
I
can
use
unsafe,
I
know
what
I'm
doing,
and
you
can
also,
of
course,
just
use
the
keyword
unsafe
and
break
all
the
rules.
A
If
you
want
to
I,
won't
give
you
examples
of
that,
because
that's
less
interesting,
but
that
escape
hatch
is
always
there.
If
you
really
want
to
write
some
code
like
you're,
writing
C,
and
you
don't
want
to
think
about
the
rules
of
correctness,
you
can
still
always
do
that
in
rust,
just
but
a
big
unsafe
block
around
your
character.
But
let's
look
at
how
you
do
this
in
a
controlled
way.
So
an
atomic
you
32
in
particular.
This
is
a
type
from
the
rust
standard.
A
Library
is
something
that
you
can
actually
modify
through
a
ampersand,
which
is
to
say
a
shared
reference,
because
it's
atomic
that's
safe.
You
have
no
risks
of
like
reading
it,
while
it's
being
written
and
seeing
a
torn
value,
seeing
a
data
race,
undefined,
usually
undefined
behavior
problems,
and
so
it's
safe
to
have
multiple
threads
access.
Is
it
safe
to
have
reentered
code
is
safe
to
have
an
interrupt
handler
access,
etc,
and
so
what
the
author
of
this
code,
the
implementation
of
atomic
in
a
very
simplified
way,
is
shown
on
the
right
side
here.
A
What
the
author
of
eCos
saying
with
this
unsafe
block
I
know
that,
even
though
this
function
takes
an
ampersand
itself,
not
in
here
percent
mute
self,
this
underlying
atomic
store-
in
this
case-
that's
an
LVN
intrinsic
that
is
actually
safe
to
do
on
a
shared
reference
and
on
a
multiple
people,
have
access
to
it,
and
so,
as
long
as
they
are
correct.
When
they're
writing
this
I,
the
application
author
on
the
Left
can
write
my
code
calling
these
functions.
A
You
32,
it
is
implemented
much
like
this
in
the
standard
library,
the
only
magical
thing
is
this
word
unsafe
cell,
which
is
an
indicator
to
the
compiler
that
multiple
people
might
be
referencing
this
data
or
might
be
writing
to
this
data,
even
through
an
ampersand
reference,
and
so
you
should
not
optimize
that
it
is
what
you've
always
wanted
if
you're
like
I'll,
just
throw
a
volatile
on
this,
but
it's
actually
defined
bigger,
and
so
this
same
pattern
is
true
of
things
like
lock
guards.
You
can
have
some
data
behind
a
lock.
A
A
So
some
more
examples
of
a
safe
and
unsafe
rust.
If
you
want
to
deal
with
raw
pointers
that
is
star,
as
opposed
to
the
ampersand
sort
of
track
reference
type.
All
of
that
is
unsafe,
but
you
can
always
just
do
that
and
so
there's
two
ways
you
can
do
that
you
can
either
write
a
function
that
has
an
unsafe
block
or
you
can
write
an
unsafe
function
in
this
case
that
first
function
there
on
the
top
left
is
probably
a
bad
idea,
because
it
is
just
taking
a
random
pointer
and
writing
to
it.
A
But
if
you
need
for
say,
I
need
to
do
a
little
bit.
Distraction
I
want
to
refactor
this
out
to
a
function.
You
can
make
your
own
unsafe
function,
the
contents
of
that
or
automatically
allowed
to
use
unsafe
constructs,
and
in
this
case
you
can
write
a
function
like
this,
where
you
say,
I
will
allocate
a
vector
vector.
Exclamation
is
another
macro
that
just
allocates
a
vector
on
the
heap
for
you,
I'm
gonna
get
a
reference
to
one
item
for
the
vector
I'm
going
to
zero.
A
It
out
print
the
contents
that
will
just
print
zero,
and
so
you
can
call
C
from
rust
pretty
straightforwardly.
You
put
the
declaration
for
the
C
function
in
rust
style
or
anything.
That's
using
the
C
API
really
put
it
in
rust,
style,
syntax
inside
an
extra
in
block,
and
then
that's
immediately
available
for
you
to
call
as
an
unsafe
function
and
then
what
you
should
probably
do.
A
What
we're
doing
in
the
next
part
of
this
is
write
a
safe
rust
wrapper
around
here
and
so
glossing
over
syntax
I'm,
basically
saying
let
me
allocate
a
buffer
here.
I'm
gonna
call
this
C
function,
which
rust
doesn't
know
sort
of
what
the
semantics
of
those
pointers
are.
So
rust
always
insists
that
C
functions
are
unsafe,
so
you
put
the
unsafe
block
around
it.
You
say
that's
fine!
What
I'm
doing
in
this
context
is
okay
and
then,
if
I
get
an
error,
I'm
gonna
return,
an
error
object
if
it
works.
A
I'm
gonna
convert
that
to
a
string.
I'm
gonna
do
a
utf-8
parse
on
it.
If
the
utf-8
parse
doesn't
work,
I'm
gonna
throw
a
utf-8
error
and
then
this
ends
up
working
and
so
I
can
just
call
this.
As
RS
read
link
from
any
rest
code,
you
can
also
do
it.
The
other
way
around
on
the
left
side
is
a
function.
I
can
compile
in
rust
and
generate
paid
or
ASO
or
whatever,
and
on
the
right
side
is
AC
program.
I
can
link
against
this
function
and
it'll
just
call
it
so
very
easy.
A
Calling
conventions
are
compatible,
they
are
not.
You
cannot
call
an
arbitrary
rust
function,
because
rust
has
a
richer
type
system,
but
there's
no
sort
of
overhead
there's
nothing
like
Segoe
or
J&I,
or
something
where
you're
like
I
need
to
set
up
the
ability
to
make.
This
call
rust
just
runs
on
the
normal
sea
stacks
like
a
normal
C
function,
and
you
can
also
access
C
types.
A
In
the
same
way,
you
put
a
structure,
you
put
this
attribute
representation
C
on
top
of
it,
you
put
whatever
it
contains,
so
in
this
case
I'm
picking
on
struct
cig
action,
because
it's
a
little
complicated.
It's
got
a
function
pointer
this
God's
flag.
It's
got
a
few
other
things,
and
I
also
am
importing
this
cig
action
function
from
the
standard
library
and
over
in
rust
code.
I
can
call
it
note
that
I'm
not
doing
any
sort
of
marshalling
on
marshalling
I'm,
creating
a
sick
action.
A
Firefox
very
notably
had
a
research
project
called
servo
where
they
were
writing
a
browser
entirely
in
rust
they
wrote
a
CSS
component
called
stylo
and
now
firefox
quantum
is
shipping
with
stylo
as
its
CSM's
engine.
They
are
writing
new
components
like
weboth
in
for
two
factor:
authentication
in
rust.
Lip
our
SVG
is
gnomes
library
for
SVG
rendering,
and
that
one
has
also
gone
thundering
on
I
think
at
this
point
a
basically
complete
rust
conversion,
while
still
providing
the
same
ABI,
api,
c,
header,
file,
etc
to
all
of
its
existing
consumers.
A
B
Cool
so
now
we're
going
to
show
you
sort
of
what
we
built
thus
far
in
terms
of
interfacing
with
the
Linux
kernel
from
rust.
So
this
is
sort
of
your
hello
world
kernel
module
written
in
rust,
using
the
library
we've
built
for
abstracting
around
the
Linux
kernel
and
exposing
it
safely.
So
we
represent
kernel
modules
as
a
trait
that
you
provide
the
init
method
on
which
maps
to
the
module
in
it
macro
that
the
kernel
header
is
exposed.
B
So
you
can
see
we
print
hello
world.
We
return
an
instance
of
our
hello
world
module
and
sort
of
print
line.
The
standard
print
API
in
rust
just
works.
Compiling
this.
We
use
something
called
cargo
X
build
cross,
build
to
target
the
slightly
different
kernel
ABI,
and
then
we
have
a
deeply
magical
make
file
that
will
convert
the
shared
object
from
X
build
into
a
o
in
terms
of
the
scope
of
what
we
interface
with
thus
far.
B
We
we
will
interface
with
sort
of
print,
K,
arrow
types,
the
whole
allocation
system,
sis,
cuddles,
very
basic
file,
system,
support,
character,
devices,
user
pointers
and
file
operations.
So
what
is
involved
in
actually
mapping
kernel
api's
to
say
for
us?
So,
let's
start
with
rust
kind
of
as
three
important
data
structures
to
get
start
with.
There's
box,
which
you
know
c++,
is
roughly
a
scanner
unique
pointer.
So
that's
a
pointer
to
a
value
on
the
heap
that
uniquely
owns
its
memory.
When
the
box
goes
out
of
scope,
the
memory
is
D
allocated.
B
Beck
is
a
heat-based
growable
linear
array.
A
string
is
a
heat
based,
linear
sequence
of
utf-8,
encoded
code
points
and
rust
has
a
global
allocator
trait
that
you
can
provide
in
your
program
to
use
something
with
sides:
live
C,
malloc
and
free.
We
provide
this
built
on
top
of
K
malloc
or
in
this
case
K
realloc,
since
K
malloc
is
an
inline
function
and
K
free
and
now
heap
allocation
is
just
work,
so
the
string,
syntax
dot
to
owned
will
allocate
a
string
that
lives
on
the
heap,
and
this
just
works.
B
So
programs
that
are
using
rusts
heap
api's
will
just
automatically
use
the
kernel
heap
in
future
versions
of
rust.
There
will
actually
support
for
managing
multiple
allocators,
which
would
let
you
do
things
like.
Have
allocators
that
use
different
flags
instead
of
always
using
gfp
kernel,
but
for
now
everything
is
just
gfp
kernel,
okay,
but
what
about
under
under
user
pointers?
This
is
you
know,
serious
challenge.
Kernels
have
like
kernel.
B
Pointers
aren't
just
like
regular
user
space
pointers
and
our
desired
goals
or
roughly
type
safety
should
never
be
able
to
mix
up
a
kernel
in
a
user
space
pointer.
You
want
to
be
bounds,
checked
really
in
both
directions,
but
you
know,
particularly
when
copying
from
user
space
to
kernel
space,
and
you
want
to
avoid
double
fetches
leading
to
time
check
time
abuse
vulnerabilities.
B
So
we
have
an
abstraction
called
user
slice
pointer,
which
you
can
you
can
pass
around
and
it
has
methods
for
reading
and
writing
to
it.
One
thing
you
will
notice
that
we
have
demo'd
so
far.
Is
all
these
methods
take
self
without
an
ampersand,
so
they
are
not
taking
self
by
reference
they
take
self
by
value,
which
also
means
self
is
consumed.
So
this
means,
after
you
call
read
all
Russ,
will
not
allow
you
to
call
read
all
a
second
time.
This
helps
prevent
the
double
touch
problem
and
so
an
example
of
using
this
is.
B
In
this
case,
we
call
right
on
every
method,
which
is
like
a
fresh
call
to
copy
to
user.
It's
like
you're
gonna
be
dropping
and
reacquiring
SMAP
after
everything.
If
you
wanted
to
pass
write
a
longer
buffer,
instead
of
passing
it
one
character
at
a
time.
You
could
also
do
that
see
you
get
sort
of
control
over
how
you
are
calling
things
like
copy
to
user
by
how
you
use
the
user
slice
pointer,
API,
okay,
but
what
about
concurrency
concurrency
is
kind
of
where
the
the
fun
stuff
happens.
B
So
Russ
models
concurrency
with
two
traits
sync
and
send
that
different
types
in
rust
implement.
So
sync,
if
a
type
of
one
sync,
that
means
multiple
threads,
may
have
references
to
a
value
of
that
type
at
the
same
time,
and
so
something
like
a
mutex
implements
sync,
because
you
can
have
multiple
threads
with
access,
but
the
mutex
will
only
actually
give
its
inner
value
to
one
thread
at
any.
B
Given
time
send
is
the
other
type,
and
this
means
that
type
may
transfer
ownership
to
a
different
thread,
so
most
types
are
send
because
they're
safe
to
give
to
somebody
else
an
example
of
a
type.
That's
not
is
something
like
a
reference
countered
pointer
that
is
not
using
atomic
operations
for
the
reference
count,
because
if
you
passed
it
to
another
thread,
then
you
could
have
races
about
the
reference
count.
So
lots
of
kernel
types
need
to
be
safe
port
concurrent
access.
B
Let's
talk
about
file
operations,
so
we've
modeled
the
file
operations,
sort
of
virtual
table
as
trait
the
different
things
in
Russ
can
influence
and
the
sort
of
colon
syntax
after
pub
trait
file
operations
says
to
implement
file
operations.
You
also
must
be
sync
in
size.
Size
is
not
probably
interesting,
but
a
file
operations
must
be
sync,
because
you
can
have
multiple
threads
trying
to
use
a
file
descriptor
concurrently
and,
as
a
result,
the
read
callback
takes
an
and
self
and
not
an
enemy
itself.
B
Because
you
has
shared
semantics,
you
can
have
multiple
people
calling
read
concurrently,
and
that
means
if
your
implementation
of
file
operations
read
needs
to
say
mutate,
something
to
get
the
state
in
order
to
work
safely.
With
the
shared
reference
you're
receiving,
you
will
need
to
bring
your
own
locking
over
whatever
state.
It
is
that
you're
mutating
and
read
so
by
designing
our
api's.
Like
this,
we
basically
force
people
to
correctly
handle
handle
concurrency.
A
Cmc
implementation
uses
lip
clink
to
read
the
header
files
and
sort
of
get
the
sense
of
what
they
mean,
and
so
we're
making
a
whole
bunch
of
assumptions
here,
and
so
this
is
sort
of.
If
we
were
thinking
about
putting
this
into
production
or
potentially,
what
would
it
look
like
to
have
this
at
Maine
law
in
today's
hypothetical
future?
This
is
one
of
the
interesting
challenges
we
are
assuming
that
clang
and
GCC
produce
binary
compatible
code
when
run
for
the
same
kernel.
This
has
been
mostly
working
for
us
in
practice.
A
One
of
the
things
we've
noticed
it
actually
fall
apart
on
is
GCC
plugins,
like
you
have
RAM
struct
running
at
the
kernel
bail
time.
There
is
no
Ram
stark
to
clinton
plugin
and
puts
the
fields
in
the
wrong
order,
for
instance,
and
so
we
would
like
better
guarantees
here
and
sort
of
a
better
way
to
sort
of
access.
This
I
don't
know
what
the
solutions
are
I'm
open
to
it's
just
we
don't
know
we're
open
to
suggestions.
A
It
seems
like
it's
probably
the
best
/,
only
tractable
way
now
but
we'd
like
some
better
guarantees,
we're
also
doing
a
bunch
of
weird
things
in
the
build
script.
It's
on
github
I'm,
not
gonna,
go
into
details
about
running
a
kernel,
build
with
CC
equals
claim
for
a
kernel
that
in
most
cases,
has
been
built
with
GCC
and
that
works.
That's
not
totally
guaranteed
to
work,
unfortunately,
and
we've
seen
some
issues
with
that
on
500
end
up
and
we're
also
grabbing
the
C
flags
which
we
need
to
pass
them
Tulip
clang.
A
So
it
interprets
things
correctly.
It
knows
what
to
define
we're
grabbing
those
by
basically
running
a
dummy
kernel
module
build
echoing
a
bunch
of
variables
that
K
build
happens
to
set
for
us,
which
doesn't
seem
great
but
is
also
remarkably
stable
in
that
I
guess
we
started
working
on
this
with
like
a
4/4
ish
kernel,
maybe,
and
it
does
still
build
up
to
5
I
tested
5.
What
this
weekend
so
happens
to
work
would
like
better
guarantees.
One
question
that
is
extremely
valid
to
ask
about:
how
can
I
use
this
for
real
work?
A
If
you
were
an
auditory
module
developer
or
we're
talking
about?
How
would
we
sort
of
start
to
pare
back
the
amount
of
C
and
Linux
main
line?
How
we
get
this
into
mainline
is
what
architectures
is
it
support,
and
so
the
architectures
on
the
left
are
the
architectures
that
rust
upstream
does
support.
So
these
are
expected
to
work
arm,
v5
plus
arm
64
horse
MIPS
plus
MIPS
1
does
not
work.
Powerpc,
PowerPC,
64
or
risk
5s,
390,
64-bit,
SPARC
user
mode,
Linux,
probably
works
x86
32.
A
The
only
thing
we're
actually
running
in
CI
right
now
is
x86
64.
So
we
should
get
that
working,
but
one
notable
thing
about
this
list.
While
it
is
a
huge
subset
or
a
bunch
of
hexagons,
you
know
other
random
architectures
in
the
arch
directory.
This
covers
all
of
the
district
hurdles,
so
rel
fedora,
Debian,
Ubuntu,
Susa,
Android,
Oracle,
art,
etc
are
all
supporting
a
subset
of
these.
Most
of
the
work
here
is
actually
in
LLVM.
We
don't
need
much
rust
supporters
and
we
don't
have
a
standard
library.
A
There
are
some
other
approaches
that
you
could
take.
There's
a
rust,
compiler
called
chem
rusty
that
commits
C
as
output,
sort
of
an
experimental
thing
that
doesn't
do
any
checking
and
then
there's
an
L
BMC
back-end,
which
the
Julia
folks
have
recently
revived.
I
have
no
idea
of
it
works,
but
it
might
be
promising
and
so
I'm
already
a
few
tree
directions
I'm
going
to
attempt
to
do
a
live
demo.
Wish
me
luck
so
over
here.
A
B
Talk
to
this,
so
we've
got
a
relatively
simple
kernel:
module
here
that
exposes
some
sis
cuddles
and
when
it
also
exposes
a
character
device
and
the
characters
rights.
When
you
read
it
gives
you
a
JSON
representation
of
your
sis
cuddles.
So
this
is
entirely
safe,
rust
within
the
kernel
module
we
have
written
and
the
JSON
module
is
like
a
pre-existing
one
like
we
did
not
have
to
write
our
own
JSON
module
so.
A
We're
we're
reporting,
sir,
to
JSON
core,
which
is
a
standard
thing
for
handling
JSON
and
rust.
We
make
three
atomic
pools.
We
make
this
empty
character
of
ice-truck
JSON
care.
Dave
went
because
we
don't
need
any
data.
We
just
need
to
implement
some
traits
on
it
and
we
basically
say
you
should
read
this
as
the
C.
Equivalent
of
you
know:
static,
JSON,
Kara,
dev,
ops,
equals
file,
operations,
etc,
and
so
we
say
when
we're
reading,
we
load
these
three
atomic
variables
and
we
put
them
into
this
output
structure.
A
We
asked
Sarah
T,
JSON
Court
is
serialized,
this
write
it
out
and
then
we
have
our
kernel
module
itself,
which
contains
three
cisco
tools.
Ampersand
static
means
it
is
borrowed
for
the
entire
lifetime
of
this
program
or
in
this
case,
the
entire
lifetime,
its
module,
and
we
have
a
registration
for
a
character
device
that
was
the
output.
Variable
I
used
I
put
the
structure
in
the
wrong
order,
but
that's
fine
and
then
here's
the
implementation
for
JSON
sis
kernel
module,
which
is
we
register
this
character
device
if
it
works
great.
A
If
not,
there's
a
question
mark
and
then
we
register
three
Cisco
tools
again.
If
it
works
great,
if
not
there's
a
question
mark,
you
will
get
an
actual
kernel.
You
know
Ian
Val
or
something
out
of
this
at
modprobe
time.
If
any
of
those
fail-
and
we
don't
need
to
do
anything
to
unregister
it,
because
we
have
destructors
that
when
these
objects
go
out
of
scope,
will
automatically
clean
things
up
all.
B
A
This
hypervisor
by
the
way,
is
qmu
with
mac
hypervisor
dot
framework,
so
things
are
slightly
exciting
with
this,
if
you
worked
on
qm
you
piper
eyes
right
framework,
that
is
very
exciting.
Thank
you
for
it
yeah.
So
that's
our
demo
and
source
for
that
is
on
github.
And
what
do
we
want
to
say
about
future
directions?
Yeah.
B
So
what
is
sort
of
next
for
this?
First
of
all,
we
think
the
future
is
bright
for
writing.
Kernel
modules
in
not
see,
particularly
in
rust,
sort
of
our
design
goals
are
to
cover
more
kernel
api's.
We
are
sort
of
relatively
limited
in
what
we
support
at
the
moment,
we'd
like
to
find
better
ways
to
support,
particularly
out
of
tree
module.
Authors
give
a
moment
for
booze
and
we
want
better
k,
build
integration.
So
more
kernel
api
is
right
now,
like
functionally,
we
have
sis
cuddles
and
we
have
character
devices.
B
We
think
particularly
exciting
targets
for
having
memory
safety
are
things
like
file
systems
and
drivers
for
various
device
classes.
So
we
would
like
to
expand
to
cover
those
real
world
out
of
tree
modules
so
like
if
there
are
any
authors
who
maintain
out
of
tree
modules
or
daintree
modules
for
that
matter
like
or
would.
B
What
would
it
take
for
you
to
actually
use
this
for
real?
We
would
love
to
whether
its
functionality
or
production
ization
find
ways
to
support
real-world
use
of
this.
We
want
better
cabled
integration.
So,
right
now
you
have
a
like
two
step
process
for
the
build.
There's
actually,
no
reason
the
makefile
couldn't
drive
cargo
X
build
and
just
have
that
all
sort
of
it
look
exactly
like
building
a
normal
kernel
module
besides
needing
to
have
rust
installed
and,
finally,
in
what
would
it
take
to
have
a
true
rust
support
for
writing.
B
A
Code
is
on
github
and
feel
free
to
check
it
out,
send
us
pull
requests
etc.
Try
it
on
your
own
kernels,
try
it
on
your
own
architectures
and
fish
in
a
barrel.
The
extremely
real
vulnerability
research
firm
is
on
twitter.
At
a
lazy
fish
barrel.
You
can
follow
us
for
more
statistics,
like
you
saw
in
the
first
part
of
the
presentation,
oh
and
we
will
be
host,
we'll
be
having
a
ball
if
anyone
wants
to
get
started
with
sort
of
getting
their
environments
that
Evan
wants
to
play
around
with
things.
A
Performance
and
code
size,
so
one
thing
I
one
thing
I
should
have
credited
is
that
there
we
are
based
in
part
on
some
other
people's
work.
There's
we're
not
the
only
people
interest
in
this.
We
think
we've
gotten
a
lot
farther
in
terms
of
sort
of
safe
abstractions,
but
there's
one
team
that
started
with
our
repo
and
made
a
real
driver
for
the
raspberry
PI's,
either
a
controller,
and
they
published
a
paper
about
it,
and
so
they
did
benchmarking
on
both
performance
and
code
size
code
size
is
larger.
A
Performance
is
quite
comparable
in
that
there
is
no
hidden
overhead
in
any
rest
operations
like
just
like.
When
you
write
see,
nothing
is
sort
of
being
allocated
on
the
heap
unless
you
call
malloc
when
you're
right,
rust
and
nothing
is
being
allocated
on
the
heap.
Unless
you
call
some
function
that,
like
you
know,
uses
allocations
in
terms
of
code
size
I
can
so.