►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Liberating Kubernetes From Kube-proxy and Iptables - Martynas Pumputis, Cilium
iptables and Netfilter are the two foundational technologies of kube-proxy for implementing a Service abstraction. They carry legacy accumulated over 20 years of development grounded in a more traditional networking environment that is typically far more static than your average Kubernetes cluster. In the age of containers, they are no longer the best tool for the job, especially in terms of performance, reliability, scalability, and operations. Companies like Google, Facebook and Cloudflare have long realised this and therefore embraced eBPF as technology, which lets one to dynamically reprogram the kernel. Can we replicate the same success story in Kubernetes? In this talk, the audience will learn about running a fully functioning Kubernetes cluster without iptables, Netfilter and thus without kube-proxy in a scalable and secure way with the help of eBPF and Cilium.
https://sched.co/Uaam
A
So
all
the
work
which
I'm
going
to
present
in
this
talk
is
going
to
be
done
in
the
cell
in
the
scope
of
the
cilium
project,
which
is
an
open-source
CNI
plugin,
and
also
a
network
security
plugin,
and
all
this
work
which
I'm
presenting
has
been
done
together
with
Daniel
Berkman,
Thomas,
Crafton,
unremarked
ins
and
other
members
from
the
Salima
team.
So,
okay,
so
this
talk
is
about
getting
rid
of
cube
proxy
from
kubernetes
and
removing
cube
in
a
way
that
we
can
still
have
this
cube.
Renatus
services
functionality.
A
So
netfilter
is
a
packet
processing
framework
in
the
linux
kernel
and
which
is
used
by
IP
tables
and
IP
vs
and
IP
tables
and
IP
vs
is
used
by
q
proxy
to
implement
the
service,
abstraction
and
IP
tables
or
IP
VSS
use,
depending
on
their
mode
in
which
keep
proxies
running.
So
before
we
start
getting
into
details,
I
would
like
to
show
you
some
demo.
So
hopefully
it's
working
so
I
have
a
little
Q&A
disclosure
and
I
have
some
pods
there.
A
A
It
works
and
then
I
will
try
to
access
the
service
from
remote
client.
So
over
the
note
port
and
again
it
works,
and
if
we
take
a
look
into
the
IP
tables
rules
which
we
have,
you
will
see
that
we
have
no
IP
tables
rules,
so
maybe
I'm
hiding
those
rules.
Let's
try
to
add
iptables
row,
let's
say
for
word
j
drop
and
we
can
see
that
oops.
A
We
don't
have
even
the
IP
tables
modules
installed
in
the
system
and
let's
check
whether
we
have
the
what
was
the
kernel
version,
whether
we
have
installed
netfilter
and
the
kernel,
whether
we
have
compiled
it
in
and
we
see
that
config
netfilter
is
not
set,
so
it
basically
means
that
the
netfilter
was
compiled
out
of
the
kernel.
So
this
talk
is
going
to
be
about
how
we
made
it
possible
that
you
can
have
the
service
abstraction
without
IP
tables
and
netfilter.
Ok,
let's
move
back
so
before
we
begin.
A
But
in
the
end
we
didn't
see-
and
we
took
a
look
into
the
kernel
to
see
what
what's
going
on,
and
we
saw
that
quite
a
huge
amount
of
time,
like
percentage
of
total
time
of
packet
processing,
was
in
iptables
modules
and
netfilter
module
to
which
I
put
in
bolt.
So
basically
that
cluster,
which
we
used
for
testing
it
even
didn't,
have
many
iptables
rules.
A
So
probably
many
of
you
got
hit
by
this
issue
where
a
cube
dns
was
taking
five
seconds
to
replies
to
your
dns
request,
and
the
culprit
of
the
issue
was
that
netfilter
had
some
race
conditions
which
got
fixed
but
I
believe
that
still
many
of
you
are
experiencing
this
issue
because
you're
probably
running
not
decent
enough
kernel
version
and
it's
understandable
because
updating
the
kernel
in
the
large
production
fleet,
let's
say,
takes
time
and
also
it's
kind
of
risky
operation,
but
also
fixing
the
kernel.
It
takes
time.
A
So,
to
give
you
the
timeline,
so
I
got
the
root
cause
of
this
issue
in
2008,
DNA
and
then
I
submitted
some
kernel
touches
to
the
net
filter
project
in
August,
2000,
18
and
those
patches
got
merged
by
the
net
filter
team.
Only
in
2000
19
February.
So
it
took
almost
half
a
year
to
merge
the
patches
and
undefined
amount
of
time
to
four
distros
to
back
for
those
patches.
A
So
another
issue
is
debugger
built,
debug
ability,
so
I
would
say
that's
kind
of
easy
to
debug
IP
table
rows
when
you
have
just
a
couple
of
them
and
you
can
use
the
packet
hunters
or
you
can
I'd
know,
add
the
new
rule
which
would
log
all
your
packets
and
you
see
which
rule
got
exactly
here.
But
situation
becomes
more
interesting
when
you
have
a
bit
more
rules.
A
So
in
this
slide,
I
tried
to
place
all
the
IP
tables
rules
which
were
created
by
cube
proxy
and
I
had
just
100
services,
which
used
the
same
endpoint.
So
unfortunately,
I
didn't
manage
to
put
all
the
rules
on
it
into
a
single
slide
and
to
add
more
fun,
cube
proxy
periodically
resets
the
IP
tables
packet
counters.
So
good
luck
with
debugging,
so
I
think
I
could
talk
more
about
what's
wrong
with
the
IP
tables.
A
I
think
I
could
spend
all
slot
about
this,
but
let's
move
on
so,
let's
better
understand:
where
is
the
overhead
coming
from
net
filter
and
I
up
tables?
First,
so
you
don't
have
to
understand
anything.
What
is
inside
those
boxes?
I
just
wanted
to
show
you
that
for
each
individual
packet
in
the
kernel
there
are
quite
a
few
steps
which
should
be
taken,
so
the
orange
boxes
denotes
the
execution
of
the
IP
tables
chains
and
usually,
as
a
user.
A
You
install
your
IP
table
rules
into
those
chains
and
those
orange
boxes
were
that's
where
the
execution
is
taking
place.
So,
for
instance,
if
we
have
the
packet
being
sent
from
outside
somewhere
to
the
pot
on
the
localhost
kernel,
first
has
to
allocate
this
skb,
which
is
the
processed
representation
of
the
packet.
A
Then
the
traffic
control
takes
place
and
then
the
IP,
all
the
IP
table,
rules
in
orange
are
executed
and
all
the
rules
inside
those
chains
and
then
the
routing
decision
has
to
be
made,
which
is
denoted
in
the
fehb
lookup
box
and
then
again,
more
iptables
chains
and
IP
table
rules.
And
finally,
the
packet
is
being
sent
to
the
one
end
of
the
virtual
Ethernet
device
and
then
that
packet
enters
into
the
network
namespace
of
the
pot
and
again
inside
that
network
name
space,
because
the
chains
are
pretty
Network
name
space.
A
Again,
you
have
to
traverse
all
those
chains
again.
So
that's
where
the
latency
is
coming
from
and
let's
take
a
look,
how
queue
proxy
takes
advantage
of
those
chains.
So
in
this
example,
we
have
a
simple
service
nginx
of
the
cluster
ap
type,
with
the
virtual
IP
allocated
by
two
brunettes
and
with
two
endpoints.
A
So
first
it
installs
generic
rule
into
the
three
routing
chain
to
steer
all
the
traffic,
regardless,
whether
it's
kubernetes
traffic
related
or
not
into
the
cube
services
chain,
where
the
matching
for
the
kubernetes
service
takes
place.
So
if
the
destination
is
three
dots,
three
dots
three
dots,
three,
which
is
the
virtual
IP
of
the
service.
Then
we
entered
this
service
specific
chain
which
was
called
cube,
SVC,
nginx
and
in
that
chain
the
endpoint
selection
is
taking
place
and
based
on
the
probability
and
either
engine
x1
or
nginx
is
chosen.
A
So
you
might
start
wondering
why
oopsie
I
think
I
miss
one
slide,
but
you
might
start
wondering
in
the
previous
slide
worthy
worthy,
whether
we
can
basically
bypass
those
netfilter
change.
Somehow
IP
tables
change,
whether
we
can
just
jump
from
the
TC
ingress
directly
to
the
TC
egress,
and
this
is
possible
with
the.
Let
me
move
here
with
the
technology,
which
is
called
EBP.
F.
A
Alternative
approach
would
be
just
to
modify
the
kernel
and
to
do
some
changes
to
Brunetti
specific
ones,
but
I
think
such
approach
wouldn't
work,
because
the
kernel
community
would
not
accept
such
patches.
You
could
also
maintain
the
kernel
your
version
of
the
kernel,
but
I
wouldn't
recommend
you
to
do
with
that.
But
luckily
we
have
the
technology
a
BPF
which
allows
us
to
jump
directly
from
TC
ingress
to
Otzi
egress
in
this
case.
So
IPPF
is
a
virtual
machine
inside
the
linux
kernel,
which
allows
us
to
dynamically
reprogram
the
kernel
and,
let's
take
an
example.
A
So
a
user
can
write
a
little
program
in
the
language
which
is
a
subset
of
the
C
programming
language
then
compile
it
with
the
C
lank
and
next
it
can
load
the
program
into
the
kernel.
The
kernel
verifies
the
program.
It
basically
checks
that
the
program
doesn't
crash
the
kernel
that
it
terminates
that
doesn't
hang
the
kernel
that
doesn't
try
to
access
some
memory
out
of
bound
memory
or
memory
from
some
other
processes,
and
then,
if
it
doesn't
reject
the
program,
a
JIT
compiles
the
program
into
a
native
machine
code
and
that
program
can
access.
A
I
can
store
and
access
its
state
from
beep,
so
called
BPF
Maps
and
this
maps
are
shared
among
can
be
shared
among
different
programs,
and
this
maps
are
also
can
be
accessed
by
processes
running
in
user
space
and
also
they
can
be
modified
and
the
execution
of
EBP
F
programs
event-driven,
is
then
driven
and
in
this
example,
we
have
loaded
the
program
at
the
TC
ingress
of
f0
device.
So
it
means
that
when
that
network
interface
gets
a
packet,
the
following
program
will
be
executed
and
this
little
program
which
I
have
probably
can
use.
A
A
So
it's
kind
of
simple
and
EBP
F
is
currently
probably
one
of
the
most
active
subsystems
in
the
kernel
and
it's
being
maintained
by
Daniel
from
the
cilium
project,
together
with
Alexei
from
Facebook
and
up
to
this
date
there
were
268
active
contributors
and
the
adoption
is
very
huge.
I
would
say
more
and
more
tech
companies
are
started
to
look
into
this
technology
and
to
adapt
and
that
you
adapt
it
and
I
listed
just
some
prominent
users.
A
So
each
request
sent
to
facebook.com
is
being
handled
by
a
BPF
program
and
also
an
interesting
fact
that
the
original
creator
of
IP
tables
and
that
filter
rested
russell
has
acknowledged.
Ebp
F
as
technology,
which
should
replace
the
IP
tables
in
the
future,
so
yeah.
So
having
this
in
mind,
let's
see
how
we
have
to
replace
the
proxy
with
EBP
F
in
the
cilium
project,
so
to
replace
Q
proxy.
We
have
to
implement
all
service
types
which
keep
proxy
supports.
So
first
one
is
the
cluster
IP.
A
So
the
cluster
IP
allows
you
to
access
bot
inside
the
cluster,
either
from
a
pod
or
from
some
host
local
process
running
in
a
cluster
and
the
access
you
can
access
it
by
using
this
virtual
IP
or
cluster
allocated
by
kubernetes.
Another
service
type
is
a
node
port,
so
you
can.
This
makes
your
services
actually
accessible
from
outside,
so
kubernetes
allocates
a
special
port
and
we
basically
use
the
notes.
Ip,
plus
that
allocated
port,
and
this
node
port
also
allows
you
to
access
services
from
inside
the
cluster
and
the
free
service
type.
A
Although
it's
not
listed,
the
service
type
is
external
IP,
it's
very
similar
to
a
node
port,
but
except
that
it
allows
you
to
access
the
services
just
outside
of
the
cluster
to
avoid
man-in-the-middle
attacks
and
the
access
happens
through
the
IP
address,
which
was
defined
by
a
user
and
the
first
one
is
load
balancer.
We
don't
have
to
do
anything
here
because
usually
it's
done
outside
the
kubernetes
cluster
by
cloud
providers
or
balancer,
and
they
are
using
the
building
blocks
of
the
cluster
EP
node
or
external
IP.
So,
let's
start
with
the
cluster
IP.
A
A
So
first
one
is
that
when
a
client
bought
sends
a
request,
we
need
to
check
that
the
destination
IP
is
of
some
service,
and
if
it
is,
then
we
need
to
select
any
endpoint
of
that
service,
and
then
we
have
to
do
the
D
net,
which
means
that
we
have
to
change
the
destination
IP
of
that
packet
into
the
veal
pot
ID,
because
previously
it
had
the
cluster
ID,
which
is
a
virtual
IP.
And
another
thing
is
for
the
reverse
path
of
a
reply.
A
A
So
let's
see
how
we
can
do
that
so
again,
I
have
a
little
BPF
program
written
in
pseudocode
English
and
basically
that
program
we
attached
to
the
TC
ingress
of
the
LXE
0,
which
is
the
device
of
the
one
end
of
a
plot
device
virtual
Ethernet
here,
and
that
program
does
the
following:
it
checks
whether
a
destination
IP
address
is
in
the
service.
Ebps
now
remember:
I
mentioned
that
programs,
vpf
programs
can
access
its
state
or
some
data
inside
the
vpf
maps
and
read
that
data
and
modify
the
data.
A
The
net
filters
cone
a
connection
tracking
table,
but
we
have
a
separate
EBP
of
connection
tracking
table
which
is
again
EBP
as
nap
so
for
the
service
we
have,
for
instance,
for
this
case,
we
have
service
map
which
contains
two
entries
for
two
endpoints,
because
previously
we
saw
that
we
have
two
engine
export
and
the
key
is
basically
the
cluster
IP
plus
port,
and
the
value
is
like
service
ID,
endpoint,
ID
and
poit
IP
address
and
and
endpoint
port
and
for
the
connection
tracking.
Again
we
have
this
e
BPF
map
where
we
have.
A
The
top
of
the
key
is
a
tuple,
basically
a
source
part
in
this
nation
part,
and
the
value
is
either
depending
on
this
sorry,
on
the
contract.
Entry
type
is
either
d
and
point
in
d
and
this
service,
because
the
first
entry
is
like
of
the
service
type
and
because
we
want
to
make
sure
that
each
packet,
which
belongs
to
the
same
connection,
is
being
routed
to
the
same
endpoint.
A
So
we
have
to
store
the
endpoint
ID
so
that
subsequent
packets
could
know
to
which
end
point
that
the
packet
requests
have
to
be
sent
and
for
the
reply,
because
we
have
to
change
back
the
source
IP
address.
We
need
to
know
to
which
source
IP
we
have
to
change.
So
for
this
we
attach
another
program
which
does
this
reverse
nap
translation
and
we
attach
it
on
the
TC
ingress
of
the
native
device
in
this
example.
A
Ok,
so
how
do
we
update
the
service
Maps?
So
this
is
relatively
simple
because
we
run
Salem
agent
on
each
node
in
the
cluster,
and
this
sodium
agent
gets
those
instances
of
cilium
agent
get
notification
from
the
cube
API
server
about
the
services.
So,
basically,
we
are
interested
in
service
object
and
endpoint
object,
and
once
we
get
those
objects,
we
parse
them
and
we
do
the
DPF
map
update,
which
is
a
sis
call
to
update
the
map
with
a
particular
file
descriptor.
So
basically
we
populate
the
service
entries.
A
Ok,
so
how
do
we
enable
the
communication
from
from
host
not
from
a
part
but
from
the
host
process,
which
is
running
not
in
the
part?
And
how
do
we
enable
the
communication
via
cluster
B?
So
we
could
imagine
that
we
have
this
client,
which
is
running
some
go
code
and
and
we
could
have
created
a
dummy
device
and
install
the
IP
route
rules
that
would
be
similar,
I
think
with
IP
vs
does
Q
per
action.
The
IP
vs
mode
does,
but
it's
not
elegant
at
all.
A
So
under
the
word
this,
what
this
client
roses
does
when
it
wants
to
establish
a
connection,
it
does
the
connect
Cisco
and
there's
a
special
set
of
EB
PF
hooks.
So
it's
called
EPP
FC
groups.
They
are
called
EB,
PLC
group
hooks
and
they
allow
us
to
attach
a
EB
PF
program
at
that
point.
At
the
particular
point
and
the
program
is
going
to
be
executed
just
before
the
TCP
or
UDP
protocol
handler
in
the
kernel
will
handle
that
particular
Cisco.
So
what
can
we
do?
A
We
can
attach
again
a
little
vpf
program
with
a
similar
thing,
but
check
the
service
map,
and
if
it
finds
that
entry
like
the
destination,
IP
and
port
belongs
to
a
service,
it
can
change
the
destination
address
and
port,
but
this
type
not
in
the
packet,
but
in
the
socket
and
it.
This
is
super
exciting
because
we,
this
is
totally
transparent
to
the
application,
as
was
in
the
previous
case,
but
the
cost
for
load
balancing
is
being
paid
only
once
just
doing
for
the
first
packet
during
the
connection,
establishment
and
the
rest.
A
The
rest
of
the
flow
even
will
not
trigger
this
PPF
program,
and
recently
we
have
enabled
this
feature
for
previous
case,
where
we
had
the
pod
communicating
with
another
pot
here:
cluster
IP,
okay,
and
we
have
the
same
for
the
connected
UDP
and
for
unconnected
UDP.
We
do
similar
thing
but
for
different
system
calls.
So
the
next
one
is
the
node
port.
A
This
is
a
bit
more
complicated,
so
let's
say
that
we
have
a
node
a
which
is
running
red
spot
and
we
have
node
B,
which
is
friend
running
engine
expert
and
we
have
a
client
somewhere
outside
outside
our
cluster
E
and
the
client
wants
to
connect
to
the
nginx
node
port.
We
are
not
IP
of
the
node
and
the
part
of
the
nginx
service,
so
it
first
sends
the
request
to
the
node
a
so
again.
A
A
We
have
to
change
the
source
IP
of
the
request,
because
otherwise
the
node
B
will
get
a
request
with
this
original
source
IP
of
the
client,
and
it
will
reply
back
to
the
client
and
it
will
not
know
that
it
has
to
change.
Also,
the
source,
IP
and
remember
I
previously
mentioned
that
the
in
such
situation,
the
packet
is
being
dropped
because
it
cannot
be
recognized
by
the
kernel.
So
for
this
reason
we
do
that
as
net.
A
A
With
this
approach,
we
kind
of
see
two
problems
is
the
first
one
that
engine
expert
doesn't
see
the
real
IP
address
of
the
client,
and
the
second
problem
is
that
we
have
this
extra
hop,
so
the
extra
hop
from
node
B
to
note
a
instead
of
node,
a
node
B,
sending
directly
back
to
apply
to
node
a
so
to
prevent
from
this
situation.
Kubernetes
has
this
special
service
annotation,
which
is
called
external
traffic
policy,
equal
local?
A
Where
does
it
basically
drops
a
request
if
the
destination
node,
which
was
to
which
a
request
was
sent
first,
doesn't
run
required
port
but
with
eb
PF?
I
mentioned
that
we
can
do
whenever
we
want
with
the
packet,
so
no
nothing
prevents
us
from
implementing
director
berry
return
for
the
note
port.
So
what
we
can
do
how
we
can
implement
this.
A
We
can
basically
before
when,
when
we
want
to
forward
attack
it
to
a
note
D,
we
can
append
into
IP
either
this
service
address
so
that
note
B
can
use
this
service
address
when
sending
back
replied
to
the
client.
Instead
of
note
a
so
in
this
example,
you
see
that
the
client
real
IP
is
being
preserved,
so
the
engine
acts
will
see
the
bill
IP
and
then
on
the
way
back.
The
note
B
will
change
the
source
IP
to
this
service
IP
and
it
will
redirect
directly
to
the
client.
A
A
Tcp
is
your
art,
so
what
it
does?
It
opens
a
TCP
connection,
sends
some
payload
sends
a
payload
back
and
closes
the
connection,
and
it
measures
how
long
it
takes
to
do
this
whole
transaction
and
because
I'm,
showing
the
latency
for
you
so
lower
is
better.
So
first
thing
to
see
is
the
first
thing
to
mention
is
that
the
our
EBP
EFT
implementation
has
outperformed
both
cube
fraction,
IP
vs
mode
and
in
the
IP
tables
mode?
Also.
A
This
time.
The
benchmarking
suit
is
reusing,
the
same
open
connection
and
basically
again
EB
PF
outperforms,
both
IP
vs
and
IP
tables,
and
this
time
we
don't
see
this
pattern
with
the
IP
tables
that
latency
increasing
increases
with
the
number
of
term
services
increasing
because
we
are
reusing
the
same
connection
and
EB
PFDs
re
has
even
better
performance
lower
latency
because
of
the
of
the
hop
being
avoided
which
I
showed
in
the
previous
slides.
A
So
to
recap,
I
have
presented
you
the
replacement
of
Q
proxy
in
IPPF,
and
this
replacement
allows
you
to
run
the
cluster
with
netfilter
compiled
out
without
IP
table
modules
and
cetera,
and
it
gives
you
a
better
performance
compared
to
q
parks
in
both
modes
and
also
it
doesn't
suffer
from
slow
service
updates,
which
I
didn't
mention
in
the
beginning,
but
basically
with
the
IP
tables.
You
cannot
update
a
single
rule.
You
have
to
update
all
the
rules,
so
the
more
services
you
have
them,
the
longer
it
takes
to
update
the
services
I,
also
reliability.
A
So
I
would
say
that
our
data
path
has
it's
very
small
and
it's
easier
to
debug
it
and
it
has
less
lines
of
code.
So
the
surface
of
bug,
surface
for
bug
is
smaller
and
also
for
security
issues
is
much
better
and
also
we
can
write
the
unit
test
for
the
networking
code
and
it's
easier
to
write
them
than
before,
for
instance,
for
the
Linux
kernel,
networking
and
also
cool
thing
is
that
remember:
I
mentioned
that.
A
Ok,
we
had
this
net
filter,
a
race
condition
and
took
a
while
to
fix,
and
also
you
had
to
compile
the
kernel
to
redeploy
the
kernels
and
with
EBP
F.
We
don't
have
this
when
I
have
to
do
this,
because
we
can
automatically
replace
the
programs
running
programs
without
interrupting
any
connections
and
yeah
again.
The
bug
ability
is
much
better.
A
Yesterday
there
was
a
talk
from
Nathan
from
digitalocean
about
debugging
psyllium
troubleshooting
silly,
and
we
have
the
psyllium
monitor
tool
which
allows
us
to
which
says
as
exactly
why
the
packet
was
being
dropped,
why
it
went
to
this
pot
instead
of
that
pot
and
why
this
decision
was
taking.
So
we
cannot
see
this
information
with
the
TCP
dump.
A
Another
thing
is
compatibility,
so
the
way
people
configure
IP
tables
they
use
IP
tables
executable
and
recently
some
distros
has
switched
the
backend
of
IP
tables,
so
some
districts
like
Debian
by
three
I,
think
they
started
to
use
enough
tables
and
it's
not
compatible
with
the
legacy
IP
tables
so
I
think
in
the
future.
We're
gonna
see
quite
interesting
bug,
reports
and
finally
customization.
So
with
the
EBP
F,
we
have
flexible
what
we
want
to
do.
A
We
can,
as
we
thought,
with
the
node
port
example,
so
we
can
modify
the
packet
and
we
can
implement
interesting
like
we
can
it's
up
to
us
how
to
do
the
load
balancing,
so
we
can
implement
different
load
balancing
strategies-
okay,
so
that
was
it
so
I
think
I
got
a
couple
of
minutes
for
questions.
So
thanks
for
your
attention,
if
you
have
some
questions,
yeah.
B
Hi
so
I
actually
asked
this
at
yesterday's
digitalocean
talk,
but
my
main
question
I
should
relate
some
more
to
BPF
than
it
does
to
psyllium,
and
you
know
with
the
the
concept
of
user
space
applications,
we've
done
a
fairly
good
job
of
you
know,
removing
a
lot
of
the
risks
and
being
running
untrusted
code.
For
example,
we
have
sandboxes,
set
comp,
app
armour
profiles,
etc.
Now
that
we're
allowing
users
to
basically
take
untrusted
code
and
run
it
directly
into
the
kernel
environment.
A
Thanks,
that's
very
good
question.
So,
as
I
mentioned,
we
have
this
EBP
F
verifier,
which
tests
a
lot
of
checks
for
us
and
also
you
have
to
be
a
privileged
user
to
allow
the
program.
So
you
can
disable
EBP
after
some
subsystems,
for
instance,
and
you
can
do
it
just
for
networking,
so
yeah
I
think
I
hope
that
answers
your
question.
Yeah.