►
From YouTube: Keynote: MDS, Fallout, Zombieland, and Linux - Greg Kroah-Hartman, Fellow, Linux Foundation
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
Keynote: MDS, Fallout, Zombieland, and Linux - Greg Kroah-Hartman, Fellow, Linux Foundation
https://sched.co/NuWK
A
Hi
I'm
Greg
I'm,
one
of
the
rare
kernel
people
in
the
world
sounds
like
I
tried
to
do
my
title
and
all
icons,
that's
MDS
fallout
zombie,
land
and
Linux,
and
my
talk
is
about
the
follow-on
with
last
year's
talk
about
secure
spectrum
meltdown
and
it's
how
you
can
make
sure
you
use
Linux
in
a
safe
way.
That's
the
main
overall
goal
here
so
again
same
disclaimer,
I'm,
vastly
oversimplifying
everything
see
all
I
wrote
down.
Good
notes,
details
how
you
can
do
this
see
the
link
it's
all
there.
A
Let's
talk
about
MDS
MDS
was
the
last
big
security
problem
that
was
released
about
a
month
or
so
ago
for
Intel
processors.
It's
the
same
type
of
family
that
Spectre
and
meltdown
was
these
are
bugs
in
your
CPU.
These
are
bugs
in
the
way
the
hardware
works
and
the
whole
goal
of
an
operating
system
is
to
make
the
user
space.
All
the
programs
like
Lena,
says,
run
well
and
make
it
not
care
about.
What's
underneath
it,
so
our
Joel,
the
job
of
the
kernel,
is
to
fix
all
the
hardware
bugs
that's
our
role.
A
Spectra
and
MDS
exploits
the
fact
that
CPUs
look
ahead
in
the
future.
They
try
and
figure
out,
what's
going
to
happen
next,
and
then
they
roll
things
back
and
when
they
don't
roll
things
back
properly,
you
can
leak
information.
There's
lots
of
different
variants
of
this
lots
of
different
ways
to
CPUs
or
very
complex
things
and,
like
I
said
last
year,
it's
going
to
be
with
us
for
a
long
time,
I'll
say
again
looking
in
the
future,
we
will
be
dealing
with
this
even
longer
it's
going
to
be
around
for
a
long
time.
A
So
MDS
is
the
generic
name.
For
all
this
classified
all
this
category,
there's
one
called
riddle,
fallout
Zombieland
and
a
few
other
names.
These
are
all
CPU
hardware,
bugs
again
variants
of
the
same
basic
idea
again
only
Intel
CPU
is
this
time
they
were
the
only
ones
found
to
have
these
problems.
Research,
researchers
tested
a
lot
of
different
chips.
A
lot
of
different
researchers
found
these.
At
the
same
time,
just
like
Dan
said,
evolution
causes
the
same
type
of
different
groups
of
people
to
look
in
the
same
areas
and
find
the
same
things
independently.
A
I
think.
There's
five
different
research
groups
that
found
this
same
problem
within
weeks
of
each
other,
which
is
amazing.
Luckily
they
all
work
together
in
the
end,
but
that
was
very,
very
rare,
but
it's
also
continuing
to
happen.
Researchers
are
keeping
looking
in
this
area.
In
order
to
fix
this,
you
need
to
do
two
things.
You
have
to
update
your
operating
system
kernel
and
you
have
to
update
your
bios.
If
you
just
do
one
or
the
other,
you
will
not
be
safe.
A
You
have
to
update
your
bias,
and
that
means
you
have
to
power
cycle
your
machine,
I'm.
Sorry
I
can't
do
anything
about
that
one
all
of
these
in
the
secure
world.
It's
not
that
big
of
a
deal
because
you
can't
modify
other
people's
execution.
All
you
can
do
is
read
other
people's
data
and
that's
fine.
A
Then
it
matters,
but
you
can
read
data
and
you
can
cross
the
virtual
machine
barrier
and
all
of
these
exploit
the
fact
that
CPUs
do
something
called
hyper-threading
or
SMT,
and
this
is
the
way
CPUs
try
and
share
resources.
They
share
the
TLB
ease,
which
is
the
low-level
way.
Cpus
look
up,
memory
addresses
and
I
share
the
CPU
cache,
but
first
level
cache
and
by
sharing
those
types
of
things,
turns
out
that
things
can
leak.
A
A
They
said
over
a
year
ago,
disabled
hyper-threading
people
laughed
at
them.
So
why
would
you
ever
do
that
and
again
in
August?
They
said:
please
disable
this.
We
think
there
might
be
air
problems
in
this
area
and
they
were
right
if
you
had
disabled
hyper-threading.
Almost
all
these
issues
are
gone,
almost
all
of
them
without
any
updates
for
the
operating
system.
Any
update
from
the
bias.
All
these
issues
were
gone.
They
chose
security
over
performance
because
when
you
disable
every
other
CPU
in
your
system,
you
will
have
performance
issues.
I
have
huge
respect
for
them.
A
They
got
this
right,
good
job,
listen
to
what
they're
doing
different
operating
systems
up.
We
didn't
know
that.
Do
this,
let's
talk
about
this,
so
riddle
was
the
first
one.
That's
the
most
popular
one
for
MDS
means
rogue
in-flight
data
load.
All
of
these
issues
are
how
CPUs
actually
work
underneath
the
operating
system
underneath
the
assembly
language
these
deal
with
how
operating
systems
work
inside
of
themselves,
and
they
have
something
called
line,
fill
buffers
and
load
ports.
Since
how
data
moves
around
inside
the
CPU.
These
are
exploits
that
up
and
application-level.
A
A
Luckily,
nobody
really
uses
this
yet
so
it
wasn't
a
big
deal,
but
from
a
researchers
point
of
view
is
a
huge
huge
deal
and
we
fixed
this
by
the
CPU
or
in
the
kernel
we
say
flush
the
buffers
every
time
we
switch
context
and,
of
course,
update
your
bios
in
order
take
care
of
advantage
of
that
flushing
fallout,
another
good
icon
that
a
good
name.
It
exploits
the
store
buffers
in
that
CPU.
This
one
is
a
little
different.
You
can't
run
application
application
or
across
virtual
machines.
A
You
can
read
from
user
space
into
the
kernel
and
the
kernel
stores
lots
of
secrets
that
you
don't
want
other
applications
to
read:
Shores
Keys
stores,
other
memory
locations
that
others
you
can
see
whether
applications
are
doing.
You
want
your
kernel,
an
application
not
to
be
able
to
read
into
the
kernel.
A
This
breaks
that
as
part
of
the
way
the
kernel
Pro
tries
to
protect
this,
we
do
something
called
randomizing
the
addresses
this
totally
breaks
that
and
our
fixes
for
meltdown
the
last
big
security
issue
actually
made
fallout
easier
because
we
thought
we
are
addressing
things
in
separate
ways.
Separate
memory,
spaces
fallout
exploits
that
it
makes
it
easier
to
figure
out.
What's
going
on
the
researchers
credit
us
for
making
their
job
a
lot
easier
again,
you
fix
this
by
flushing
the
buffers
in
the
kernel,
updating
your
bias,
Zombieland
great
logo,
great
marketing.
A
A
You
can
open
another
window
with
the
applet,
what's
a
problem
in
it,
and
you
can
see
what
the
other
windows
doing
huge
huge
marketing
win,
grand
cool
name,
we
fix
in
the
kernel
flushing
the
buffers
every
contacts
which
we
handled,
we
moved
on
and
again
there's
other
variants
to
other
Gribbs
store
to
leak,
forwarding
meltdown.
You
see
these
are
all
little
tweaks
on
the
same
general
idea
same
areas
in
the
processor.
Again,
you
can
steal
data.
You
can
just
read
data
across
the
security
boundary.
A
Again
we
fix
the
buffer
to
fix
the
problem
by
flushing
buffers
flushing
buffers
is
slow,
there's
the
reason
we
never
do
this
before
and
the
reason
the
BIOS
never
did
this
before
is
because
this
slows
things
down.
You
don't
want
to
slow
things
down
every
time
you
call
them
to
the
kernel,
and
now
the
kernel
traditionally
system
calls
in
and
out
have
been
fast.
Now
we
have
to
flush
these
buffers.
It
slows
things
down
a
way
to
get
around
this
is
you
can
take
every
logical,
CPU
and
only
run
logically.
A
Success
secure
be
wise,
the
same
type
of
problem
process
here
and
over
here.
It's
a
really
hard
problem
academically,
they
fixed
it
in
reality,
they
haven't
yet
something
called
gang
scheduling.
There
are
kernel
patches
out
there
to
solve
this.
To
try
and
do
this.
It
really
is
slow.
It's
getting
better
Microsoft
for
Windows
actually
has
this
option
you
can
enable
it.
If
you
care
about
it,
slows
your
machine
down.
It
is
one
way
to
potentially
mitigate
these
issues.
It's
not
ready
for
primetime.
Yet
the
best
way
to
do
is
disable
hyper-threading
and
update
the
kernel.
A
That's
the
only
way
to
solve
all
these
issues
you
can't
do
both
or
one
or
the
other.
You
have
to
do
both
a
lot
of
operating
a
lot
of
Linux
distribution,
just
recommending
just
disable
hyper
threading
and
moving
on,
but
doing
that
slows
things
down.
My
development
I
read
lots
of
email,
I,
write,
lots
of
email
and
I
do
two
things
really
I
build
kernels
a
lot
and
then
I
create
a
kernel
locally
and
shove
it
off
to
another
machine
to
build
it
there.
A
Building
kernels
is
very,
very
CPU
intensive,
I,
more
processors,
I
have
the
better.
It
goes.
This
slows
my
workload
down
if
I,
don't
disable
hyper
threading.
It's
about
two
percent
slowdown
which
is
kind
of
in
the
noise
I
do
disable
it
it's
noticeable.
Fifteen
percent
decrease,
that's
real.
That's
a
real
performance
hit,
I
notice.
It
takes
extra
couple
minutes,
don't
like
it.
My
kernel
creation
is
single
threaded
though
I
take
a
get
tree
clone.
It
apply
a
whole
bunch
of
patches
to
it.
A
Tar
it
up,
send
it
off
to
another
machine,
all
single
threaded,
SMT,
disabled,
no
workload,
difference
at
all
same
amount
of
time,
identically
so
run
the
test
yourself
test,
your
own
work
load.
Everybody's
workload
is
different.
We
all
use
Linux
in
a
different
way
to
solve
your
own
problems.
It
might
be
that
this
doesn't
affect
you
at
all.
It
might
be
affect
you
a
lot.
We
don't
know
so
all
depends
again.
A
A
The
bad
part
about
this
is
now
you
have
to
choose
performance
or
security
and
that's
not
a
good
option.
Anybody
ever
wants
to
make,
and
you
are
relying
on
your
cloud
provider
also
to
make
that
choice.
I
have
a
number
of
test
machines
in
the
cloud
my
cloud
provider
made
the
choice
to
go
performance
over
security,
look
and
see
what
yours
did
I'm
now
switching
cloud
providers.
A
You
might
need
to
see
what
your
provider
does.
What
did
they
choose?
What
do
they
care
most
about?
There's
a
website
called
Meg
Linux
fast
again,
it's
kind
of
a
joke,
but
it
gives
you
the
command
line
to
change
your
kernel
boot
to
rip
out
all
the
security
things
we've
done
to
make
things
slow
and
make
it
faster
again.
My
kernel
builds
or
15%
faster.
Now,
if
I
make
it
again,
that's
how
much
things
have
decreased
in
the
past
year.
A
A
Did
we
deal
with
this
Linux
last
year,
with
spectrum
meltdown
was
involved
really
really
late
in
the
process
until
silo
2
saw?
Wouldn't
let
us
talk
to
each
other.
It's
reaction.
We
reacted
after
it
was
even
public.
It
was
a
total
complete
nightmare
on
our
part
and
on
you,
as
a
user
this
time
around
and
so
got
it
better.
They
worked
with
us.
They
brought
us
in
really
early.
Most
of
us
didn't
really
early,
not
all
of
us,
and
we
got
it
done.
A
A
I
will
credit
the
Debian
developers
for
actually
doing
more
work
than
most
all
the
other
distributions
in
getting
this
to
work
right
because
they
had
to
scramble
at
the
very
last
minute
and
they
did
a
great
job,
because
if
you
rely
on
Debian
most
the
world
does
this
stuff
was
impacted.
They
did
a
wonderful
job,
so
that
needs
to
fix.
Intel
needs
to
bring
W
earlier.
As
always,
when
we
have
private
announcements,
we
can't
have
all
the
developers
look
at
it.
A
We
don't
see
all
that
weird
workloads,
we
don't
see
all
the
odds
CPUs
out
there
fixes
come
in
afterwards,
so
we
fix
things
like
instantly
afterwards,
because
we
had
some
reports
things
we
just
saw
patches
yesterday
that
made
things
go
a
little
bit
faster
because
we
didn't
need
to
do
some
of
the
things
we
did.
So
you
can
make
things
go
a
little
better
fixes
keep
coming
all
the
time
they
keep
coming
every
week.
You
have
to
keep
updating
your
kernel
to
make
sure
you're
correct.
It
wasn't
just
the
original
announcement.
A
It's
all
the
updates
that
come
after
that.
You
also
have
to
take
and
update
your
bias.
You
have
to
update
your
bias,
the
it
will
not
work
without
that,
so
updating.
Every
week
we
do
a
security
lease
release.
I
do
a
new
kernel
update
every
week,
we're
running
about
22
changes
per
day
in
these
patnik
kernels,
so
one
a
week,
a
whole
bunch
of
patches
come
out.
At
least
one
of
those
fixes
every
week
is
a
security
issue.
Sometimes
we
don't
know
until
years
later,
because
in
the
kernel
we
treat
a
bug.
A
As
the
bug
is
a
bug,
we
don't
know,
if
it's
a
security
issue
or
not,
we
don't
care,
we
fix
it,
we
move
on,
we
get
it
out
to
the
world,
it's
up
to
you.
Take
it
whole
thing
update
your
scenes
and
then
you
know,
you're,
secure
and
people
look
at
see
bees
see.
Bees
is
the
way
of
tagging
security
issues
at
the
community
or
the
world
has
been
using
for
a
while,
and
you
notice
very
few
kernels
see
our
kernel
issues
our
CVEs.
A
Okay,
a
very
small
number
of
the
fixes
we
ever
do
in
the
kernel
go
to
CBE.
If
you
try
and
just
cherry-pick
kernel
a
CBE
to
this
fix
to
that
one,
the
backported,
you
will
get
it
wrong
because
there's
follow-on
fixes
if
you
looked
at
spectrum
meltdown
that
was
like
80
patches
and
then
it
was
like
an
18
other
patches
after
that,
and
we
never
tagged
them
all
for
all
the
CV
geez.
We
didn't
realize
it
so
later,
and
this
is
not
how
Linux
works
with
security.
I
have
a
link.
A
There
there's
a
whole
big
long
article
about
how
this
kernel
security
team
works.
You
can
download
the
presentation
go
to
the
link,
read
that
this
is
how
we
work
again.
Very
very
few
kernel
issues
are
actually
get
real
CBE's.
One
of
those
security
researchers
did
look
at
all
the
past
work
that
we've
done
in
ten
years.
Twelve
years
we
only
had
a
thousand
CPUs
for
the
kernel
I'm
doing
20
fixes
a
day
that
is
a
hugely
in
disproportional
amount
of
what
is
really
going
on.
The
weird
thing
about
kernel.
A
Cbe's
is
the
average
time
between
when
you
apply
for
a
CVE
and
when
the
bug
is
fixed
for
the
kernel
is
negative
a
hundred
days.
So
that
means
a
hundred
days
later.
Somebody
says:
oh
look
that
issue
you
fixed
a
long
time
ago.
That
really
was
a
security
issue.
Let's
go
get
this
number,
so
we
can
track
it
easier.
That
means
for
100
days.
If
you
hadn't,
updated
your
machine,
you
actually
we're
vulnerable
to
that
issue,
but
the
data
is
skewed
all
over
the
place
again,
40
percent
are
negative.
A
A
So
I
worked
with
this
Google
security
team
and
trying
to
figure
out
how
is
the
best
way
to
do
this
stuff
and
they
looked
all
last
year
they
go
and
they
look
through
all
the
research
and
find
all
the
problems
that
are
public
and
all
the
problems
that
aren't
public
and
they
tell
the
pixel
security
team
for
Google
phones.
Take
this
patch
take
this
patch.
Take
this
patch.
We
want
to
make
sure
our
phones
are
up
to
date,
whatnot
and
they
identified
last
year,
218
different
issues.
A
They
said,
hey
go
take
this
patch,
it
turned
out
every
single
one
of
those
92%
of
those
issues
were
already
fixed
and
already
released
in
a
public
LTS
kernel
a
stable
kernel.
They
were
already
there,
the
only
ones
that
were
not
or
code
for
that
they
had
imported
into
their
tree
from
not
upstream
kernel
or
things
that
they
had
back
ported
incorrect
everything
that
was
there
that
they
identified
was
already
fixed.
Their
phones
were
already
secured
before
they
realized
it.
So
now,
Google
Android
recommendations
is
you
have
to
take
the
LTS
kernel
updates.
A
Take
it
every
three
months,
I'm
happy
every
one
month
would
be
wonderful.
Some
manufacturers
are
doing
it
every
month.
There's
one
manufacturer.
It
is
very
good.
They
push
in
your
kernel
updates
every
month
on
some
every
three
months,
some
not
at
all,
watch
this
look
at
the
kernel
version
number
of
your
phone.
If
you
want
to
see
how
secure
your
devices,
this
is
real
proof
that
taking
new
kernels
is
the
only
way
you
can
be
secure.
You
have
to
take
these
kernels.
A
In
fact,
I
said
this
a
couple
years
ago,
when
these
other
conferences,
the
only
way
you
can
ensure
that
you're
running
a
secure
machine
is,
if
you're,
using
the
latest
LTS
kernel
or
stable
one
or
working
with
the
distribution
that
does
it
themselves.
Debian,
very
wonderful,
Sousa,
wonderful,
Red,
Hat,
wonderful
use
rely
on
them,
they're,
very
good
at
that,
as
well.
If
you're,
not
relying
on
that
and
using
your
own
kernels,
which
is
great,
you
can
do
that
too.