►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The Cross-Platform Future of eBPF- Dave Thaler, Microsoft
In this session, Dave Thaler, partner software architect at Microsoft and lead of the effort to bring eBPF support to Windows, discusses the opportunities and challenges in taking eBPF from a Linux-based technology to an industry-wide, cross-platform initiative.
A
All
right
welcome
back
from
lunch
hope
everybody
had
a
great
lunch.
I
know
like
I
said
this
is
the
time
where
the
food
coma
starts
to
set
in
so
I'll.
Try
to
keep
you
awake
and
that's
why
I
was
wondering
if
we
can
up
the
lights
a
little
bit
on
this
side
of
the
room,
because
you
know
so
I
don't
fall
asleep
later.
A
So
all
right,
so
we're
going
to
talk
about
the
cross
platform
future
of
ebpf
and
I'm
going
to
try
to
keep
this
part
at
a
relatively
high
level
kind
of
vision,
and
I
work
at
microsoft
in
the
part
of
microsoft
that
owns
the
core
operating
system.
So
we
own
the
ebpf
stack
for
both
linux
and
windows,
okay
and
across
microsoft,
there's
many
different
types
of
applications
and
things
that
are
represented
in
other
speakers
and
so
on.
The
kind
of
usb
ppf
under
the
covers.
A
So
I'm
the
group
that
owns
the
core
platform
between
linux
and
windows.
So
I'm
going
to
talk
about
the
cross-platform
future
of
ebpf
and
since
this
is
right,
after
lunch,
just
to
make
sure
we're
all
still
awake,
I'm
going
to
start
off
with
a
question.
Okay,
once
one
question
quiz:
okay,
now
they
say:
if
you're
going
to
give
like
a
keynote
style
presentation,
whatever
you
should
start
off
with
maybe
a
provocative
statement,
a
provocative
question.
A
So
this
is
it
right,
so
here's
my
quiz
to
see
if
we're
all
awake
now:
okay,
whether
you
know
anything
about
ebpf
or
not,
you
can
still
vote
or
whatever.
Okay,
here's
the
quiz,
one
question
quiz,
true
or
false:
okay,
there's
only
two
possibilities:
it's
multiple
choice:
okay
ebpf
is
a
linux
technology
that
can
run
sandbox
programs
to
extend
the
linux
kernel.
A
A
Okay,
so
we
said
why
would
this
already
be
false?
Okay,
because,
obviously
the
talk
is
about
the
future
right,
but
I'm
going
to
back
up
and
talk
about
the
past
briefly,
here:
okay,
so
linux
technology
to
extend
the
linux
kernel,
I'm
going
to
claim
that
that
is
already
false.
Let's
look
at
some
history
here:
2014,
okay,
that's
when
ebpf
kind
of
came
in
to
augment
or
replace
the
classic
bpf.
So
when
we
say
ebpf
as
we
know
it
today
started
in
2014.,
you
could
argue
that
the
sentence
was
certainly
true.
A
Then,
okay,
now,
as
we'll
see,
the
extent
to
which
you
think
it's
true
or
false
depends
on
where
you're
talking
about
what's
used
mass
in
production
versus
what's
available
in
projects
and
things,
and
that's
why
I
said
you're
all
right:
okay,
so
back
in
2014,
that
sentence
was
certainly
true:
okay,
but
even
only
a
year
later
the
user
mode
bpf
project
came
in
and
that
one
said
well.
I
wanted
to
allow
ebpf
programs
to
be
run
in
user
space.
A
A
2017
was
a
big
year,
so
a
couple
things
came
in
in
2017.
we
had
the
rust
bpf
project.
That
said,
okay,
we're
going
to
run
things
as
a
rust
crate,
and
not
only
user
mode
for
user
space
for
linux.
Okay,
by
the
way
I
use
user
mode
user
space
depending
on
which
ecosystem
you're
in
you
use
the
same
charts
use
different
terms
for
the
same
thing.
If
I
mix
and
match
it's
because
I'm
thinking
cross
platform
thinking
linux,
I
call
it
one
term.
If
I'm
thinking
windows,
I
think
of
another
term,
and
so
on.
A
So
with
rust,
it
already
done
work
to
make
it
work
and
say
user
mode
for
mac
os
right.
It's
just
a
rust
crate.
Right
later
in
2017,
okay,
you
had
to
release
the
first
release
of
android,
which
is,
of
course
you
know
based
on
linux,
so
that
part
wasn't
hard,
and
then
you
had
the
generic
ebpf
project.
A
A
2018.,
okay,
rust
creates
okay.
Now
there's
some
initial
work
and
saying
I
want
those
rest
creates
to
also
be
able
to
work
on
top
of
windows,
so
now
user
space
in
windows
and
then
the
beginning
of
this
year,
we
at
microsoft
announced
the
ebpf
for
windows
project
that
says:
okay,
we
want
to
allow
running
ebpf
programs
in
windows,
kernel
mode,
okay,
the
latest
one
in
this
long
line
of
history
here
and
then.
A
The
last
piece
has
been
talked
about
a
couple
times
during
the
conference
already,
and
that
is
hardware
offloads
right
once
you
can
take
a
program
and
run
it
down
inside
the
the
network
interface
card
as
liz
and
others
talked
about.
Well,
it's
not
running
in
the
kernel
anymore,
okay,
and
so
that's
yet
another
platform,
and
that
is
in
production,
use
right
and
so
between
user
space
kernel
space,
linux
non-linux,
the
main
cpu
alternate
cpus
network
cards,
all
these
different
places
that
can
host
ebpf
programs.
A
So
here's
the
revised
version
that
I
would
say
is
my
vision
and
I
hope,
a
vision
that
we
all
share.
Okay,
which
is
ebpf,
is
a
cross-platform
technology
that
can
run
sandbox
programs
to
extend
a
privileged
system
component.
Now
that
privilege
system
component,
it
could
be
the
kernel
okay,
it
could
be
a
network
interface
card.
Okay,
it
could
be
a
user
space
demon,
that's
a
privileged
demon
or
it
could
be
anything
else,
a
separate
processor,
whatever
it
is
right.
So
this
is
the
future
vision
that
I
hope
we
all
share.
A
So
how
do
we
make
this
become
a
tool
that
we
can
use
in
as
many
of
these
environments,
because
it's
a
powerful
tool,
there's
exciting
things
you
can
do
with
ebpf
right
the
same
exciting
things
you
can
do
with
the
linux
kernel.
People
want
that,
for
the
other
cases
too
right
in
the
windows
world,
we
had
people
asking
us
for
windows,
features
that
ebpf
already
provides.
Okay,
do
we
invent
something
different
for
windows,
or
can
we
just
take
ebpf
and
make
that
common
technology
be
cross-platform?
A
So
if
this
is
the
cross-platform
vision,
there's
some
challenges:
okay,
one
of
those
being
usability.
So
I
said
what
is
the
usability
vision,
that's
necessary
to
enable
the
cross
platform
vision
here,
two
pieces.
The
first
piece
is
to
make
sure
that
it's
easy
to
build
a
cross-platform,
ebpf
application.
A
Okay,
there's
many
people
that
build
platforms
or
build
applications
or
solutions
or
products
that
are
based
on
abpf,
typically
built
for
linux,
okay
and
think
about
what
what
could
you
do
if
your
product
or
your
application
could
be
run
on
other
platforms
too?
Suddenly,
a
much
broader
user
base
much
broader
applicability
for
the
same
product.
How
do
we
make
that
be
easy
right
today?
Is
it
easy?
A
It's
probably
not
easy
today
right,
how
do
we
make
it
become
easy?
Okay,
that's
the
vision.
The
vision
is
that,
where
we
want
to
go
is
that
it
becomes
easy
to
build
things
that
are
cross-platform,
okay
as
easy,
it
is
to
say,
you
know,
build
a
kubernetes
plot
and
deploy
it
on
a
bunch
of
different
systems
right
to
go
along
with
that.
How
do
I
deploy
those
things?
A
A
Okay,
so
we
said
okay,
if
these
are
the
things
that
we
want
to
get
to
okay,
what
are
some
of
the
attributes
that
it
takes
to
foster
the
success
of
getting
here
right?
The
more
attributes
are
present,
the
faster
it
will.
The
transition
will
happen
to
be
cross
platform
and
easy
and
same
tool
sets
across
platforms
and
the
fewer
of
the
attributes
that
I'm
going
to
show
you
then
the
harder
it
is.
It's
not
that
you
won't
get
there
it'll
take
longer.
A
So
let's
look
at
some
of
the
attributes
and
we'll
talk
about
some
of
these.
So
here's
my
list
of
good
building,
block
attributes,
okay
and
I'll
talk
in
the
next
slide
about
what
the
building
blocks
are.
Let
me
talk
about
what
makes
for
a
good
building
block
a
good
piece
of
technology
that
goes
along
with
ebpf.
Okay,
now
again,
not
all
of
these
are
necessary
in
all
projects,
but
all
of
these
are
success.
A
Contributors
they're
all
things
that
are
synergistic
with
success:
okay,
the
first
one
is
of
course,
security
because
ebpf
you're
extending
a
privileged
system
component.
It's
kind
of
table
stakes
right
now.
You
have
the
classic
security
things
you
might
think
of,
but
there's
some
other
parts
of
security
that
kind
of
vary
between
projects
and
that
can
help.
So,
for
example,
do
you
have
the
the
building
block
built
in
a
type
safe
language,
and
that's
where
you
saw
things
like
the
rust
bpf
project
come
in
that
says.
A
Okay,
can
I
write
all
these
things
in
rust,
because
then
my
core
implementation
that
building
block
becomes
safer?
Okay,
that's
one
example:
do
I
do
testing
in
ci
cd?
Well,
do
I
do
fuzz
testing
for
each
of
these
different
components?
Okay,
all
these
things,
the
things
that
fit
into
the
security
attribute
of
a
particular
building
block
open
source.
A
Well,
we
kind
of
all
understand
that,
when
it's
easier
to
use
stuff
across
platform,
when
it's
open
source
easier
for
people
to
port
and
so
on,
but
not
just
open
source,
but
if
we
look
back
at
that
matrix
that
I
showed
you
of
all
those
different
projects,
there's
at
least
three
or
four
of
them
that
came
in
that
were
brand
new
implementations
of
something
because
the
pre-existing
one
did
not
use
a
permissive
license.
Okay,
so
we
found
that
permissive
licenses
are
far
more
open
across
projects
and
to
facilitate
cross-platform
work
than
restrictive
license
projects.
A
Okay,
so
again,
some
of
them
vary
by
license
documentation.
There
is
some
great
documentation
out
there,
but
often
people
will
list
that
as
a
challenge
in
learning
ebpf.
Well,
it
wasn't
well
documented
or
the
documentation.
Is
you
got
to
go
and
read
the
linux
source
code?
Okay!
Well,
that's
a
barrier
if
you're
trying
to
do
development
for
one
of
those
other
operating
systems.
You
know
whether
it's
you
know:
mac
os
or
freebsd
or
windows.
Or
what
have
you
to
say?
A
A
Some
compilers
are
meant
for
specific
os's,
especially
when
you
get
down
into
embedded
and
other
variations.
That
we'd
like
to
see
ebpf
go
to
obviously
there's
the
platform
agility.
Is
it
written
just
for
linux?
Or
can
it
be?
You
know,
agnostic
like
generic
evpf
was
my
example
there.
If
it
was
nicely
platform,
agile,
execution,
context,
agility.
A
What
I
mean
by
that
is,
it
meant
to
run
a
particular
building
block.
Is
it
meant
to
run
in
the
kernel?
Is
it
meant
to
run
in
user
space,
or
is
it
a
static
library
that
you
can
compile
and
run
either
way
as
well
see?
There
are
some
projects
that
are
easy
to
do,
no
matter
whether
it's
kernel
or
a
user
easy
to
move
around,
and
that
means
it's
easy
at
building
block
to
be
used
in
multiple
different
assemblies.
A
That
I'll
show
you
in
a
bit
all
right
and
then
finally,
I'm
having
the
source
tree
separate
from
the
platform
tree.
Okay
and
I'll
give
an
example
or
two
there:
okay.
Well,
I
shouldn't
have
to
like
compile
linux,
to
do
the
windows
version
or
compile
freebsd
to
do
the
mac,
os
version
or
whatever
or
even
you
know,
grab
sources
out
of
it
if
there's
a
better
way
to
do
it,
so
those
are
some
of
the
key
attributes.
A
So
this
is
a
list
of
the
typical
building
blocks
that
make
up
an
ebpf
runtime
solution.
Okay,
so
you
have
a
compiler.
You
have
something
that
can
load
ebpf
programs,
it's
a
library,
that's
used
by
apps,
you
have
a
verifier,
you
have
either
an
interpreter
or
a
jit
compiler,
and
often
both
meaning
the
choice
of
them.
You
have
an
ebpf
program,
execution
contact.
This
is
where
the
ebpf
programs
run
and
it
exposes
general
functionality
like
the
ability
to
have
you
know,
maps
and
so
on.
A
Some
of
those
might
be
inherently
specific
to
a
single
platform
right
and
so
today,
when
you
look
across
the
attributes,
what
you'll
find
is
that
I
mentioned
in
that
matrix
there
all
those
different
projects
for
every
single
one
of
those
building
blocks.
There
exists
multiple
implementations.
Already,
okay,
you
can
see
a
list
of
them
there,
okay,
so
that
comes
with
both
opportunities
and
challenges.
There's
benefits
to
that
right,
which
is
that,
of
course,
it's
goods
to
be
used
across
platform
and
all
these
different
scenarios
and
context
and
the
challenges
we'll
talk
about
briefly.
A
A
A
A
So
this
is
the
classic
assembly
in
linux.
Okay,
where
your
compiler
tool
chains,
your
loader
libraries,
are
all
in
user
space,
but
the
verifier
jit,
compiler,
assembler
and
execution
context
are
all
in
kernel:
okay,
that's
the
classic
one
that
evpf
has
had
for
years,
but
that
doesn't
mean
that
the
other
systems
that
I
showed
have
exactly
that
same
assembly.
A
Okay,
here's
the
one
that
we
have
in
ebpf
for
windows.
So
a
couple
things
to
note
here
right,
the
compilers
and
loader
libraries
are
still
there
in
in
userland.
Okay-
and
here
you
see
things
like
the
execution
context
and
the
interpreter
are
still
in
the
kernel,
but
there's
a
couple
things.
There
are
differences
here
and
this
is
to
illustrate
that
there's
many
ways
to
assemble
the
same
building
blocks
right.
If
I
showed
you
the
diagram
for
any
of
the
other
projects
that
might
look
like
a
different
assembly.
A
A
So
I'll
talk
about
a
couple
things
highlighted
here
so
first,
probably
the
most
prominently
visible
is
in
the
top
right.
Okay,
where
the
verifier
and
the
jit
compiler
are
not
in
the
kernel
here
they're
in
another
protected
address
space:
that's
not
the
normal
user
land
space;
okay,
it
is
in
fact
in
user
land,
but
this
could
be
in
a
secure,
vm,
isolated
from
the
regular
system.
It
could
be
inside
of
something
like
of
an
sgx
enclave.
A
A
So
if
you
think
about
the
discussion
and
trends
you've
heard
about
people
talking
about
maybe
signed
ebpf
programs
right,
so
one
of
the
visions
is
that
part
in
the
secure
environment
could
even
be
on
a
completely
separate
machine.
Maybe
it's
in
your
back
room
or
something
like
that,
generating
the
sign
programs,
and
you
only
have
a
checker
in
the
kernel.
Okay,
and
so
this
notion.
That
says:
where
is
the
stuff
running?
Sometimes
in
the
future?
It
may
even
be
on
another
machine
right.
So
that's
the
promise
of
like
the
secure
the
signed
programs.
A
So
that's
one
concept
here.
Another
concept
in
here
is
in
the
top
middle,
where
you
see
the
lid
bpf
and
I'll
come
back
to
this
on
the
next
one.
You
see
bpf
tool
and
lib
epf
right.
Our
goal
is
that
those
are
exactly
the
same
libraries
and
tools
as
you
have
on
linux
or
on
any
other
operating
system
and
as
I'll
mention
in
a
bit
there's
some
challenges
there.
This
is
work
actively
in
progress.
A
Another
thing
to
keep
in
mind
is
the
key.
That's
in
the
bottom
left.
Okay,
the
key
that's
on
the
bottom
left
says
this
project
is
called
ebpf
for
windows,
not
ebpf
in
windows,
because
all
the
ebpf
parts
here
are
not
in
the
windows
product
now.
The
reason
for
that
is
because
we
wanted
to
work
with
already
shipped
versions.
We
don't
want
you
to
have
to
wait
for
the
next
windows
kernel.
A
That's
not
ebpfcimbox
versus
the
things
that
are
really
cross-platform
agnostic,
like
the
ability
to
support
maps
right,
which
is
in
the
execution
context
right.
So
the
point
is:
there's
different
drivers
in
the
windows.
Sense
kernel
modules
in
the
linux
sense,
okay,
but
separate
where
the
hooks
and
helpers
are,
and
the
execution
context
allows
for
multiple
of
these
things
to
be
plugged
in
over
time.
A
Okay,
that
this
presents.
When
I
say
this,
I
mean
all
the
previous
slides,
so
there's
a
bunch
of
heterogeneity,
okay,
there's
lots
of
implementations,
of
a
verifier,
there's,
implementations
of
an
interpreter
and
so
on.
How
do
we
deal
with
this
case
when
there's
multiple
implementations?
Okay
and
then
you
vary
by
features
right.
Somebody
adds
a
feature
to
one
and
then
somebody
add
the
same
feature
to
the
other
one.
What
is
ebpf
is
a
specific
set
of
features.
Well,
if
you
add
a
feature
to
one,
does
that
change
the
definition
of
evpf?
A
A
First,
our
opportunity
is
to
drive
that
feature
consistency
across
those
implementations
as
much
as
we
can
right
to
get
that
coordination.
If
somebody
adds
a
feature
into
one
of
the
implementations,
how
do
we
make
that
feature?
Be
common
across
implementations
right
number?
Two.
I
think
this
one
came
up
in
the
evp
summit.
If
I
remember
right,
it
says
to
create
common
test.
Suites
right,
do
we
actually
have
stuff
be
tested
in
ci
cd?
If
you
have
multiple
implementations,
can
you
use
the
same
test
suite
think
about
a
verifier?
A
If
I
got
multiple
verifiers,
can
I
have
a
set
of
sample
ebpf
programs
that
the
verifiers
all
use
the
same
set
to
test
verification
with,
as
an
example
right
same
things
for
the
other
ones
for
for
an
interpreter
or
whatever
else
number?
Three,
we
just
created
the
ebpf
foundation.
Okay,
the
ebf
foundation.
One
of
the
goals
of
the
bpf
foundation
is
to
help
evangelize
what
is
evpf?
What
is
that
common
feature
set?
How
do
we
get
coordination
across
projects?
A
Okay,
so
that
we
don't
have
just
silos
or
ships
in
the
night
happening
and
different
people
different
projects,
implementing
different
things
without
coordination?
How
do
we
get
that
coordination?
Kind
of
the
central
focus
of
that
coordination?
Is
the
ebpf
foundation,
okay,
and
so
we
would
love
to
have
more
people
join
the
ebpf
foundation
and
to
help
and
help
with
the
coordination
collaboration.
If
you
have
a
project
want
to
share
across
other
projects
and
stuff.
A
A
A
So,
for
example,
today,
if
you
look
at
bpf
tool
or
lib
bpf
sources,
you'll
find
intermixed
linux
kernel
specific
code
and
generic
code.
That
is
really
not
specific
to
linux,
all
intermixed,
okay,
that
is
a
problem
for
taking
those
to
be
cross
platform,
meaning
it's
a
problem.
That's
not
insurmountable!
It's
just
work.
Okay,
when
you
take
those
things
and
easily
factor
them
such
that
the
code
that
is
can
be
used
across
platform
is
clearly
separated
from
the
code.
That's
really
specific
to
the
linux
kernel.
Why?
So?
A
So
there's
a
couple
of
opportunities
there,
which
is
to
separate,
as
I
was
just
talking
about
again,
to
improve
the
documentation
to
make
that
be
easier
and
the
hooks
and
helpers
I
mentioned
in
the
linux
exam.
Sorry,
the
windows
picture
that
some
of
those
were
generic
things
like
working
with
maps
versus
very
platform.
Specific
things
like
cooking,
a
special,
the
ntfs
file
system
or
something
in
windows,
is
to
make
those
be
cleanly
separated
all
right.
So
those
are
some
of
the
major
challenges
and
opportunities
that
we
look
forward
to
working
on
today.
A
So
let
me
wrap
up
with
three
key
takeaways.
Okay,
number
one
linux,
sorry
ebpf
is
not
just
for
the
linux
kernel
anymore
and
you
can
argue
it
hasn't
been
for
a
long
time,
especially
since
we
started
having
smart
knicks
and
so
on.
Okay,
it's
been
since
2015.
It's
already
been
on
the
road
to
being
not
true,
so
it's
not
just
for
the
linux
kernel
anymore.
We'd
love
it
to
be
as
many
places
as
possible.
A
Number
two:
the
community
is
already
enabling
an
ecosystem
of
cross-platform,
apps
and
products
right
if
you're
developing
code,
we
want
it
to
be
easy
for
you
to
develop
code.
That
is
not
linux.
Only.
You
might
be
a
linux
expert
right,
but
can
you
develop
code
that
will
work
on
these
other
platforms
too
right?
Can
you
develop
code
that
will
make
it
work
attached
to
say
a
linux
user
space
daemon,
not
just
the
kernel,
okay,
to
make
it
be
possibly
easy
to
create
products
or
applications
or
demos
or
whatever
that
are
already
cross-platform
and
number
three.
A
There's
lots
of
interest.
There's
people
joining
the
evp
foundation,
so
the
takeaway
to
me
is
the
future
of
ebpf
as
bright.
This
is
an
exciting
time
to
be
here.
Working
on
ebpf,
because
this
is
where
it
will
really
blow
and
go
blow
across
the
industry
not
only
to
the
linux
kernel,
where
it's
already
huge,
but
also
all
to
the
rest
of
the
ecosystem,
and
so
with
that.
I'd
like
to
thank
you
for
being
here
taking
time
after
lunch
and
I'm
happy
to
take
any
questions.
A
Yeah,
so
the
question
was
specifically
about,
I
don't
know
if
they
can
hear
if
the
remote
people
can
hear
that
so
I'll,
just
repeat
the
question
once
you
have
hooks
and
helpers
and
things
to
deal
with
like
sk
buffs,
which
might
be
inherently
linux
specific.
How
do
you
deal
with
that,
because
you'd
have
to
rewrite
the
application
to
use
something
else?
Okay,
so
there's
a
couple
of
different
you're
right,
I
mean
there's
a
couple
different
variations
there
that
says
well
sockets
themselves
right.
The
bsd
sockets
model
is
exists
on
almost
every
platform.
That's
out
there.
A
Okay.
Now,
as
you
mentioned,
the
data
structure
itself
may
vary
okay
to
say
what
is
it
on
bsd
versus
linux,
versus
windows
versus
something
else,
and
so
sk
buffs
is
a
very
linux
specific
way
of
doing
it.
Okay,
so
you
have
two
choices.
You
can
either
say
I
want
to
have
if
depths
and
things
like
you're
talking
about
where
I
have
a
different
port
for
each
of
these
different
things,
I
could
create
a
new
hook
or
new
helper
that
uses
a
generic
version
or
I
could
find
a
way
to
shim
sk
buffs.
A
On
another
thing
and
say
I
want
to
copy
it
into
that
structure.
Those
are
really
the
three
choices
that
you
have:
okay
and
those
same
three
choices.
We
have
on
windows,
the
same
ones
you
have
on
bsd
or
whatever,
which
one
do
we
collect.
If
we
want
to
do,
that's
something
that
I
think
we
want
more
input
from
the
community
know
what's
the
right
way,
but
those
are
really
the
only
three
choices
right
now.
A
Fortunately,
most
of
the
hooks
and
helpers
that
are
out
there
can
be
done,
cross-platform,
okay,
now,
meaning
all
three
of
those
approaches
can
work
like
the
shim
approach,
wouldn't
work
if
there's
nothing
to
map
to
right
so
but
yeah,
those
are
the
types
of
things
we
actually
struggle
with
and
saying.
How
do
we
bring
it
to
windows
or
in
the
generic
bpfks?
How
do
we
bring
it
to
bsd,
and
so
on
is
exactly
those
questions
so
you're
spot
on.