Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/1030 Thanks!
[Music]
you may heard about
meltdown and
Spectra inspector 2 inspector NG
inspector RSB inspect what the [ __ ] um
to bring light into this mess moris lip
M Schwartz Daniel Gru and clao canel
will give us an overview of all proposed
mitigations and show us that an attacker
still can run an attack desperate condom
measurements please welcome on stage
morit Mel Daniel and
claudo
we will start our talk with a video and
for that we will go off
stage can can we turn the lights
off
[Music]
okay oh what a messy Christmas Day heard
the people
speculate cringing eyes are twinging oh
what a messy Christmas Day after a time
of half a year
canes cause some fear a of traces
morning chases oh what a Messing
Christmas Day
reasoning was not all say that Kaiser
was much
sted by an
engine
meory who brings a higher Pace people
try to
replicate Twitter people posting Cod L
is break
[Music]
Theo in the
new no more
Christmas meryy
Christmasy Mery
Christmas
[Music]
[Applause]
[Music]
Christmas
welcome welcome to my little talk about
uh performance of computers I like Fast
computers who else likes fast
computers who bought a new computer this
year yes and we want all our computers
to be super fast and of course we used
in our talk we have some materials from
other people and we acknowledge them
here and we also um present results here
research results where we collaborated
with a lot of people and of course this
was funded by uh different parties for
the full acknowledgement see the papers
but I will start with performance is
awesome and this is what this talk is
about performance is awesome and for me
when I was a bit younger uh the pensum
pro uh 1995 this was quite awesome
because this machine had 150 mahz quite
nice and uh it was the first Intel
processor that uh was risk emulating CIS
which is quite nice uh because um this
allows you to do something which I will
have in the next point but also it had
uh 256 kiloby level two cache integrated
into the CPU so it was not separately on
the main board but in the processor
itself very nice and Branch prediction
BR we love Branch prediction and out of
order execution this is what we get here
from the risk emulating CIS out of order
execution now we can schedule small bits
of uh code on the actual processor so
the future also is going to be fast
because we are getting faster and faster
more and more performance for instance
Apple in the new iPhone introduced uh 16
kilobyte Pages as the standard page size
the minimum page page size and that
allows them to introduce 128 kilobyte
level one caches that's larger than the
level one caches in Intel processors so
cash is super nice oh Daniel Daniel not
so fast I'm Mar Spector of the
past
okay and probably you see you only want
performance but that's not everything
that comes with it so for instance
imagine a program no bugs at all no
vulnerabilities but apparently this does
not mean that the software that is
executed is actually
safe because information can leak from
the underlying Hardware from your
performance improvements that you
celebrate here not if you don't have any
software bugs right that's not the case
because you can exploit this leakage
through side channels for instance you
can look at the power consumption or the
execution time of your algorithm yeah
sure then you know that it consumed a
bit more power what do you learn from
that I mean whatever a lot of Ry and
also CPU
caches but more importantly before we
dive into those topics is to understand
the difference between architecture and
microarchitecture all of us know
instructions at architecture like rv8
x86 and this is just an abstract model
of a computer but actually there's an
interface between hardware and the
software and how those instructions are
implemented is defined by the micro
architecture and this is where things
get interesting yeah yeah this is what I
made with the risk and CIS stuff right
yeah because we all know AMD Eon ryzen
core i7 Kon and so on and they all are a
bit different and they are quite fast I
like them yeah that's true but this also
is a problem
sometimes and all of them have many
elements in order to improve performance
in order to achieve different tasks
efficiently so they contain multiple
microarchitectural elements for instance
cions and buffers different predictors
like the branch predictor Daniel
mentioned and so on and the nice thing
is they make everything faster that's
nice thing and they are transparent for
the programmer so he doesn't notice at
all he runs the same program on a
different microarchitecture and
everything is faster but since
everything is faster in some cases we
have timing optimizations and therefore
timing differences and as we've learned
earlier those timing differences are
side Channel leakage and we can exploit
it but no one knows what you can learn
with that right oh a lot and actually
sure I also optimized something during
the Christmas holidays because I needed
to cook something and cooking is nicer
so I wanted to cook something I prepared
the board everything to cut and then I
figured out damn I'm missing the
vegetables I'm missing the tomatoes the
bell peppers so I need to go to the
supermarket and this takes a lot of time
and then I come back now I have my
tomatoes and the bell peppers so I can
start cutting and then I figure out I
wanted to cook some
spinach so what do I do I go again to
the supermarket this takes a lot of time
every everything everyone is hungry so
this sucks but then I can continue
cooking so what I did I invented
something and it's amazing because what
I did I used things you do in the
processes and apply them to everyday
life for cooking so I invented a food
cache and it's amazing because now I can
store everything there and I do not have
to go to the supermarket again did you
just explain processor caches by cooking
yeah because it's relevant yeah h no so
actually since I'm the Spectre of the
past I've been here two years ago and
I've told you something then in a
different talk about x86
microarchitecture and some of the part
you didn't listen to apparently so we'll
repeat so for CPU caches imagine you
have a variable ey and you want to
access it so it's not in the cache so
you have a cache Miss and then you have
to do a look up in the main memory and
this takes some time you send a request
there the main memory will respond and
the value will be loaded into the cache
so the second time when you want to use
this variable it's already in the cache
so if we have a cache Miss we need to do
a DM access so everything is slow but on
the other hand if we do not need a DRM
access because the value is already in
cash it's fast and it's doing exactly
what it's supposed to do and it makes
makes everything better yeah but don't
you see a problem here I don't see a
problem here it's getting faster and
more efficient that's true but imagine
if an attacker can measure that he just
has a high resolution timer measures the
excess time to a memory address and if
it's in the cache it's pretty fast but
on the other hand if it's not in the
cache it's much slower as we've seen so
what an attacker can do he can figure
out a threshold in between to
distinguish if a variable has been
loaded into the cache or not and he can
build powerful attacks with that for
instance the Flash and reload attack
imagine the address space of an attacker
on the left and the address space of the
victim on the right and they use some
shared memory like a shared Library this
means an address from the shared library
is cached for both the attacker and the
victim what the attacka Now can do he
can use an unprivileged instruction on
x86 the seal flash instruction to remove
this data from the
cache this means the data is not in the
cache for both the victim and the
attacker of course now the victim is
scheduled he can either access the
address in this case he does which will
transparently load back the value into
the cache and what the DEA can do now he
can again access the measure uh measure
the access time of this variable and
figure out if the victim has accessed
the address or not
and this is very nice as an attacker
because you can build powerful attacks
with that really really what can you
build with that so for instance what you
could do by just looking at Cash hits
and misses you can leak AES keys from
the cach that's just academic attacks
right can't really do that you can also
look at keystroke timings with the cache
or build a covered Channel using the
cache to transmit some data from one
Android application to the other forance
so the academic say yeah and you can do
this in the browser in the cloud in
trusted execution environments like
trust you can't prove that it actually
works oh I do because I have a demo with
me so here we see a Samsung Galaxy S6
and the victim opens his favorite
messenger and tries to send a message
and this spy application which does not
need any permissions and privileges on
the system which just used the cach to
figure out whenever the victim typed
something and he can distinguish between
alphabet letters the space the back
space figure out the length of the words
seriously yeah this this is just
metadata you're interrupting my talk on
performance for metadata go off stage no
go off stage I I want to continue with
my talk on Fast
computers really so I talked about the
apple and there actually more
interesting features for instance Intel
um since a long time is improving more
and more on out of order parallelism and
they also announced something new there
and to understand that I want to explain
um out of order execution and that's
again because Mor's already talked about
cooking maybe we should also talk about
cooking we all cook uh make cookies
during the Christmas holidays or before
the Christmas holidays and usually we
want them to look like this and uh
usually what we start with looks like
this and there's some way in between and
usually it involves stirring everything
and forming small balls and then
pressing them flat and putting them in
the oven and afterwards you want to dip
them into chocolate but the problem is
if you wait until the cookies are
already done you're losing some time so
actually you can save some time by now
while the cookies are in the oven uh
preparing the hot chocolate and then
dipping them into the hot chocolate
afterwards when they are ready and the
hot chocolate is ready so everything's
perfect and everything's faster I saved
a lot of time here so this is great and
we can do the same thing in
computers oh Daniel
Daniel don't you listen to the specs of
the
past it's me Michael Spectre from the
present so with that we get another
whole lot of problems here don't you see
you're kind of opening the box of
Pandora with that that's that's not good
what you're doing loud of order here
it's it's again a problematic
performance optimization imagine you
burn the cookies in the
oven and then you can't dip them in the
chocolate so if someone sees the
chocolate you have they know you were
trying to bake cookies which you
apparently screwed up really you're
trying to explain me that they learn
that I try to bake
cookies yes that's again metadata right
oh no it's it's quite more than
metadata we can do a lot more with that
let's look at it on an computer science
level so we have an simple program here
that has some variables and calculates
the diagonal and the area of some
geometric figure and if you look at that
we go through it line by line usually
but the computer could do an optimized
variant of that by figuring out what the
dependencies are of the Cod lines and
what it could parallelize so the same
this is just what I explained right yeah
the same thing you do with cookies the
computer does with code or we
Illustrated here with code in
if we actually look at the hardware
level it's not the code lines but we go
down to instruction level so it's
basically more a kitchen in your
CPU um this is the out of order
execution and it it looks a bit more
complicated than your kitchen and
there's a lot of more things in parallel
so you have your instruction stream from
the application going in the all the
instructions are fetched and then
decoded in the front end and then we
dispatch it to the back end with have
some scheduling there and then we have a
lot of execution units that can do a lot
of things like an oven and they are
processed by the individual execution
units I I was about to explain all this
in my performance talk what what what
what do you want to tell me here yes so
you still don't see a problem with that
it's it's a nice performance
optimization I agree with that but still
there's a problem I did an experiment
look at my code here so I I wrote two
lines of code really you're accessing a
n
pointer yes it's a problem are you
expecting this to do anything
useful you expect it to did you try
that yeah I mean first I tried to
compile it my compiler was not so happy
about it what a
surprise um my static code analyzer
wasn't happy either as it's a d
reference of an Al it will crash here so
you that the same it will crash after
the first line Second Line This access
to the memory will never be
executed so that's what what you think
what the compiler thinks but I tried it
of course and what
happens I do a flush and reload attack
like the Spectre of the past told you
and I can see that the memory axis
actually happened so this line was
executed although it should have crashed
before but that's fine it's just running
in parallel and this doesn't leak any
information so you say this is out of
order execution and it's fine yeah and I
can't abuse that for anything right so
it's not a problem that they leave kind
of traces if you do things out of order
and you leave traces like chocolate for
the burnt cookies it's not a
problem when we can see them in the
microarchitecture and all these elements
then we give them a name call them Trans
in execution so we have something to
talk
about and then we can see this execution
of your out of order instructions and if
you now think about how it actually
works if we D reference an address if
you load something from the memory then
we try to read an address then we have
the memory management unit translating
the addresses checking this bits the
permission bets whether we can actually
read that if the permission bits are
fine everything is okay and we get that
data from this address but if we don't
have permission to read that for example
because we try to read privileged m
memory the memory management unit tells
us nope and kills the
application so we're gone that's what's
supposed to happen but and that's what
happens here right that's what happens
here but let's get back to my experiment
and combine that so before that I had
this null po D reference which doesn't
make a lot of sense but if I replace the
access to the null binder with an access
to Kernel address some privilege m
memory I'm not supposed to read it will
still crash it will crash I agree but
then I use this data which I do not get
according to you and use that as an
index to an
array and access the memory
there and then I check whether any part
of the array is actually cached whether
I can see any access to this array and
if I do that
huh I get a cach it at exactly this
array index which corresponds to the
data which I was not supposed to read
yeah that's bad that's
bad because the permission check but but
this is I mean
you're plots here and this is from some
academic paper this does not work in in
in in practice right oh if if we do that
we can actually read data from the col
we can read any data that's stored
currently in memory and even quite fast
this is not the fastest but I can read
all your secrets your browser history
for example okay you don't like that I
guess yeah this is quite bad but um I
think we can do something against that
right yeah so that's what we call
meltdown and you agreed this is actually
quite bad so two years ago I showed you
some other attacks which you can look up
in the talk which we linked earlier but
the issue is quite obvious what you're
doing is you access and kernel address
while you're running in user space so
obviously this is a huge
problem so why don't we just take those
addresses and remove them if we do not
need
them because the user accessible check
in Hardware which you explained to us
obviously does not work and it's not
reliable in every case if you can mount
such an attack Daniel didn't believe
that he will learn EV
eventually so how can we mitigate melt
toown we just start unmapping the kernel
while we are running in user space and
then the kernel addresses are no longer
present and if they're no longer present
no one can access them because the
memory which is not mapped cannot be
accessed at all and actually this is
what we implemented in our Kaiser batch
which is now ported to Linux Windows Mac
OS in a much better fashion but
basically what it does is imagine you
have the user space on the left with the
applications and the kernel on the right
and you imagine this process isolation
as a huge wall and no application can
crab through this wall to access the
data but with meltdown they can so what
we do now is by changing the way the
operating system is working when we are
running in the kernel mode the user
space is is there but when we running in
user mode and the attacker tries to
mount the same attack punching through
the wall nothing is behind it and this
is nice because the Melton doesn't
work so okay yeah but then this problem
is solved and we can think of other
things maybe performance oh wait wait
wait wait wait this just fixes the
Meltdown vulnerability but actually
there's more similar thing than that so
do you think about virtual machines
virtual machines yes sure so we are
talking about native code but there are
no real machines so no real problems
right
yeah we we still have virtual machines
and we use them all the time and of
course because we use them all the time
we have a lot of performance
optimizations for virtual machines like
for the address translation so that we
can do a more efficient address
translation from virtual machines to ual
physical memory and that perfectly makes
sense and that makes sense to make it
faster but again we might have a small
problem here so if we for example are in
a virtual machine like virtual box and
then we have some page table that
references some physic page and it's
present of course then we can the
references and access the memory there
we have this small step in between so
that these addresses in the virtual
machine are translated to actual
physically addresses and this physical
addresses then reference a physical page
and we get the data from the physical
page and of course we do a look up with
the physically address so that we can
check whe it's already in the cache the
performance optimization and get the
data from that
faster but what happens if we try to
dreference an address in a virtual
machine which is not
present probably it won't access
anything which makes sense yes then we
don't have to do this guest host
translation thing and what some
processes might do is then they just do
the cash look up which they shouldn't do
and it because they don't have a
physical address with the virtual
address and the virtual address is
controlled by the virtual machine so by
the user so they can basically read
everything from the level one cache yeah
that's also quite bad but Intel actually
said they fixed that they said they
fixed that so what are you still doing
on stage here go go away so let me
continue about performance this is about
this talk is about performance and I
will get back to this slide uh so Intel
introduced more ports more parallelism
and um larger reorder buffers and this
is all great because it makes our
computers more effective more efficient
and uh faster uh
so let's look at other vendors maybe AMD
AMD introduced a new perceptron based
prediction mechanism for branches this
is also quite nice and to understand how
Branch prediction actually works we um
again take some analogy um because it's
Christmas of course we always thought
always thought how Santa manages to uh
have all the Christmas presents ready
just in time right because Santa doesn't
know who gets a present and who doesn't
because there's this uh suda incidence
file
[Music]
and Santa doesn't know who is going to
enter sudo although he's not in the sudo
as file one day before Christmas so what
senta does is centa of course wants to
get rid of bottlenecks and have more
efficiency there so Santa will use the
Naughty Nice List from the last year
because probably if you didn't enter
pseudo and on a machine where you don't
have pseudo right rights you probably
won't do it this year right that's
perfectly made perfectly makes sense
yeah and then the evening Before
Christmas Center checks where the
predictions correct did the user behave
the same way as the year before and then
the user gets a present and if not then
well then we have to throw away the
wrongly manufactured presence and we can
correct the predictions um in and and
all the predictions that were correct
result in free time that's perfectly
fine oh no oh no I don't know so many
things that can go wrong here so many
things this is about Christmas and
presents what can go wrong what can go
wrong have you heard about
Spectre they actually exploit this
optimization you invented for
Santa and how do they do that so talking
about now computer science again because
all you Christmas performan thingies um
let's talk about computer science so we
have have some code here we have some
data in memory and it's kind of an array
and we can access some data there which
we can access which we allowed to access
like the text before and then in memory
we have something else like a secret
crypto key which we are not allowed to
access for obvious reasons and the user
can now provide us some index of this
memory which he wants to access to print
some string for example and then because
we write good code we check whether this
index is actually in the range of this
array and if it's fine if we can only
access the first four characters of this
data then we do some look up in a lookup
table because for example we want to
convert it to
uppercase so if the user access some
valid characters it's fine it will be in
this index but you already speculate
whether this condition will be true or
not so you have no idea where this
condition will be true but you just
speculate and like I have no idea but I
guess it will be
wrong and in reality it's correct so
after you actually executed you know
whether it was correct or not and you
remember that like the list from s
Center you remember the outcome of this
condition the last time on the next time
the user asked for some character next
one is also a valid one he said it was
okay in the past this if was true in the
past so it will be true again because
why would anything
change and you speculate that you
already do this memory accesses
speculatively and then you see it was
correct we're already done and we saved
time that's great and you saved a lot of
time so it's fine as long as the user is
a good user and doesn't try to do
anything
illegal then the user says let's try to
read something I'm not supposed to read
like this key here and the user provides
an an index that's out of bounds and
would re reference some of these secret
values there
you said in the past oh this if
condition was always true so it will be
true again speculate do a memory access
again but now with this data which the
user is not allowed to access already do
the memory access we can do the flush
and reload again and learn the secret
value and then say Oh what's wrong
whatever execute else Branch discard
everything else but the
microarchitectural state already changed
so you leak the values from it just by
predicting a simple if
condition and then it continues and user
can read basically arbitrary memory you
update the prediction a bit but you say
in most cases it was true so it will
always be true it's fine sure but who
would write code like that yeah no one
does bounce checking for array
accesses who does that
right and that's not the only thing you
try to predict so if our CPUs try not to
only predict if conditions but also
calls for example if you write C++ you
have some classes some veral functions
and then you have some object with a
function and you have an animal and it's
a it's a bird and it has a move function
and it could fly or Swim but usually a
bird flies so you predict something
think of a duck yeah but usually not all
the time and then you execute the fly
function and
you the CPU remembers that and next time
you call the move functionality it cost
it speculates on the fly but if we then
change the instance of the object to
something else like a fish and a fish
usually doesn't
fly then you still speculate on a fly
because it was the same in the past and
you have basically a speculative type
confusion
here and something was executed with the
wrong data of some instance of an object
and because this is still not enough we
have more predictions in our CPU to
predict more things like returns we have
some victim some attacker and the victim
has some secret value like a secret
crypto key and attacker is nothing and
if the victim calls some function with
some short running code and the attacker
calls the same function with some long
running code then we have this return
stack buffer where the CPU remembers
where the last call came from and now
the first uh code that will return is
the victim because has the short running
function but it will take the address
speculatively from the return stack
buffer and return into the attacker's
code and then the attacker can again use
speculatively the secrets from the
victim because we're in the wrong
control flow here until it sees oh no
what's wrong just discard everything but
we leaked all the values through the
microarchitectural elements yes and all
the time you explaining this with data
and this memory access this is all just
the same like meltdown Spectre this is
all the same no no no that's not the
same come on that there are different
attacks and different problems in our
CPUs so if you're talking about Spectre
attacks we have some operation here and
at some point we predict something CPU
predicts something and it predicts the
control flow or some data flow depending
on what kind of Spectre attack we're
talking about and this all happens
transiently so it doesn't know whether
it's correct or not it might discard
it and at some point the operations
retire so they're actually executed and
done and at this point the CPU knows
whether the prediction was correct or
not and can discard it or keep it so it
saved a lot of time this is Spectre but
for meltdown with also some operation
and another operation that accesses data
and another oper operation with a data
dependency so it needs the data from the
previous
instruction and this is fine but if this
second instruction has some exception
because it was not allowed to use this
data then everything that happens
afterward is a transient execution it
should never happen because that's not
supposed to happen nothing is supposed
to happen after an exception but
exception cannot be raised immediately
but only at retirement
so the correct thing would be to discard
the data of the instruction and give the
data dependent operation just some dummy
data like null or
random but if you optimize this step
out of this carding the value you get
the
Meltdown and then you can leak the
privilege data so there are there are
quite a few differences here okay okay
so there are two vulnerabilities Spectre
and mown and Intel already fixed them we
know and the other is fixed with the
software patch so I can now continue
with my talk on performance right can I
uh you can
try okay let's continue with performance
so um AMD this prediction based
mechanisms they are really quite
nice oh Daniel you still haven't learned
anything from the spects of the past and
the present another ghost yes so let me
because you haven't learned anything now
let me the spect of the future tell you
what will happen if you don't stray from
your path so you say you like
optimization what will normally have or
you need normally do to update the the
access rights of a page you would have
to uh normally you would have to um to
um context switch but that's fine yeah
you need to do a context switch but you
also have to modify the page table entry
Flash the tlb and that is slow you hate
slow right okay so we have a new
technology called Intel mpk memory
protection keys in the protection key
you can assign a protection key to a
group of pages you can use the four bits
in the pte that were not used so far and
that allows you to do a quick update
because you can do it for a whole range
of addresses okay that's nice so sounds
nice right yeah I like performance but
what happens if we see the same problem
that we see
before because we can also see meltdown
in with mpk because the protection keys
are lazily enforced so the data that we
protect with it is actually forwarded to
the um to the transit instructions and
as the spec of the past has told you you
can observe the value in the cache
Ah that's bad it's bad right yeah so
what if a different thing is we have we
all perform bound control we have um but
it would be nice to have something that
we that would do it automatically so we
have an instruction for that x8x gives
us an instruction like that and if we
exceed the accepted range we get a bound
range exceed at
exception but then we also have here the
problem that the data is used in the
trans and
execution and we can again use flush and
reload to observe the value in the cach
so this is two new Melton variants yes
these are two new Melton variants and if
you remember um AMD always claimed that
they are not affected by meltdown well
they are not affected right well let's
look at this they said back then okay we
are not affected meltdown so if you're
running Linux on an AMD processor uh we
just disable everything that is related
to to Kaiser and they said this back in
2017 and the problem is here now this
new version of meltdown is actually the
first meltdown attack on AMD so you
cannot Escape meltdown but just
switching to
mendor and we can see here that you
cannot even switch to arm or something
else because we have two new variants
here with Melton mpk and BR that work on
Intel and with PR that works on AMD and
we have also observed so many different
um or tested so many different versions
with different faults that we do not
that do not work either on Intel arm or
AMD but but uh are we certain that they
don't work or might they work in the
future we are fairly so we tested them
but who knows maybe our experiments
failed okay we are still human wow or
you are still human
um but let's talk about defenses we can
categorize meltdown defenses in two
groups the first one is we try to
eliminate the the data that is
architecturally access inaccessible
shouldn't be accessible in the in the
microarchitectural level so if we can't
cannot do that we are fine the different
thing is we can simply prevent the
occurrence of faults if there no
fault we don't get
meltdown and the Spector of the of the
present also told you about for Shad or
melt on p as we call it and you said
that Intel claims well that solved
everything but let's look at how they
try to solve
that um we can simply clear the physical
address field because if we don't have
the address field of the UNM pte then we
cannot read data from the from the cache
because it isn't access anymore and when
we switch to protection to main we can
simply flush the L1 because if there's
no data in there what can we
leak so that's the future apparently but
we are still in the past and the present
right I doubt that this actually works
oh oh it it does so so what you're
saying is you can so first of all is
your system fully updated I have an
updated Ubuntu
18.4 I guess okay and so my software is
up to date and I have this virtual box
running and I I implemented this for
shadow exploit I really like that and we
were talking about Santa and Santa of
course has this nice and naughty list
but it's a huge list everyone does Pudo
without being rude right so he needs a
nice naughty list
manager uh to to keep track of of all
the the nice and and notu
people
and and now I want to use my virtual
machine it's just a virtual machine it
can't escape if we have an escape from
ver Bo that's really bad we're just
using this forhow to read the password
entry from this nice naughty list
manager in real time here so because
with for shadow we have seen before we
can read everything that's in the cache
so what is currently used and this nice
naughty list man has some nice features
because it gives me some address where I
can actually read that so I don't have
to look through the whole cach and then
you time for that you want to read the
password that sender enters yes but we
don't know the password we don't know
the password yeah that's a flaw right we
didn't think that true does anyone know
the password of Santa any ideas what the
password could
be pseudo pseudo okay okay let's let's
see
oh I can in in real time leak it here in
my virtual box whatever Santa
[Music]
enters so I can do whatever I want can
spy on everything so yeah future might
fix that but we are still in the present
where this is not
fixed wait why is this not fixed it
should be fixed right oh no yeah it
should be fixed but it has so high
performance overhead that nobody
actually does that now I lost you lost
the presentation I think I lost the
presentation yeah that's not good but we
can look a bit more at the demo it is
also very nice it's it's a nice
Center it we we need some Jeopardy
Sounds
here yes that's good louder
oh no again the wrong
one yes
yeah now we're at the beginning again in
case you missed
something yeah we will start from from
the
beginning Where Have You Been yeah click
somewhere there that will be fine I
think it's just oh no come
on yeah nearly so a short recap
can't do it now fast forward we need
more performance optimization it's a bit
slow here it's still oh you're already
too far oh oh no I'm too oh no okay
there we need more performance okay but
now you can leave the
[Music]
stage okay so let's continue so we have
we have this transing cause we can
classify all these attack attacks that
we call Trans and execution attacks with
some some simple questions if we have a
prediction we have Spectre if we have a
fault we have Melton and
then um we already saw these versions
but what if if we what is if we can
mistra the prediction in a different
place so far we've seen that we uh that
we mistra it in the same place with
Spector V1 yeah yes but what is if we
can mistra it and a different address
but but why would I do that because it
allows an attack to to Target something
else that's bad or even worse what is if
we because the brage prediction state is
shared what is if we can do it from a
different place or externally at in
another process for instance or on the
operating system yeah so we have these
new Mist trining strategies and we can
we analyze them so we have for Intel we
were able to show that our new Mist
trining strategies worked very well for
arm some worked some did not yet work
and for AMD the same as for R okay but
with all these variant isn't there
anything where we can say something like
we can eliminate all the out ofpl
attacks or something or all the attacks
in general well we have an optimal
solution we call it the drilling
template if you drill at exactly the
do you have any do do you have any
serious counter measures okay if you
want serious counter measures let's talk
about serious counter
measures just with as with meltdown we
can categorize it into three different
categories we can mitigate or reduce the
accuracy of our cover channels so we can
observe the data we can mitigate the or
board speculation or we can ensure that
our secret data cannot be reached at all
because it cannot be reached cannot be
leaked
and we can see here we have so many
different defenses why why is this so
empty I mean are we is this completely
lost or no because so most of the
defenses don't consider all
microarchitectural elements and if you
don't if you don't consider it then it
might still be able to be exploited just
by using a different um just be using a
different micro element so for side
isolation we saw a lot of boxes colored
before yes we saw a lot of box of
colored and what is side isation well we
execute each side in its own process
this limits the amount of data that we
can that is
exposed and so far it is the default in
Chrome 67 and Firefox is working on it
so you're basically reducing Spectre to
meltdown and if I have a meltdown
defense then it's secure okay yes sounds
reasonbly and then we can look at a
different medication let's look at
serialization if we insert instructions
that simply stop the speculation then we
should be fine and we insert it after
every bounce check but this disables
speculative execution and we have this
on x86 x86 and on
arm another more serious um attempt to
stop Spector is invis spec if we make
the the jent load invisible at all how
can we leak dat
by simply using a speculative buffer and
if we have the correct prediction we
load the data into the cache and if it
is wrong we just throw it away but this
is in Hardware we don't have that in
Hardware yes yeah but I can't install
that in my computer now no you
can't
so how do we have some analysis of that
well we have so many different versions
and we analys and we looked at them for
all vendors and we can see that for
instance in this back saves back we can
theoretically argue that they do not
work in others like side desolation does
not work in all cases and but it works
in some cases it works in some cases yes
so that's nice so we have done this for
Intel arm and AMD looks all pretty
similar yes they're pretty similar and
we can also have or we have another
problem with that because some um
because they they they only defend
against some some of the cases that's
quite bad right so I have to combine
them yes you need a combination of
different mitigations and each one costs
performance so with this we have seen in
recent weeks that stip for instance has
been introduced but because of the
performance impact it was thrown out
again and with Linux 420 it can be
enabled but it is off by default so how
much use do you have of a defense that
is not not
enabled let's return to to our
classification we have we have already
seen this part we have discussed the
Mist trining strategies and in previous
work we have disc or we have seen these
versions so there are some obvious gaps
here are there yes because these are our
new Mist training strategies where we
showed that these work as well and in
meltdown we have the same thing we have
seen some that work and we have those
that we showed that did not work some
that we already knew and some that we
did not know yet but who did not work
and those that
works okay so wow that were many many
attacks but how did we end up here I
think I'm
outnumbered yeah there are more ghosts
than you so apparently we have ignored
microarchitectural attacks for a long
long time I mean two years ago I told
you about some attacks and nothing has
been done and the things are we showed
attacks on
crypto yeah but the software should be
fixed that was everybody said that so
fix the software don't care about the
side channels but how about the tax on
aslr aslr is dead anyways who uses aslr
for a useful counter measure it's it's
broken anyway we don't care about that I
use
aslr but
how about trusted execution environments
I mean attacks on sgx or trust Zone
where I say I put my software and
everything is secure well those they
they are not part of the Frat model so
you can't consider those ah I wouldn't
say so and how about rowhammer I mean
some of those attacks improve the rammer
attack and you can just flip arbitrary
bits get rude well those only affect
some cheap modules so but the but the
prevalent studies said 80% do you say
80% is some cheap modulus
yes I I think I think I I so I I realize
more and more that for years we solely
optimized for performance and maybe this
was not all good I mean you were
standing here and saying performance
performance performance now I can't
remember that oh
okay so
apparently optimizations always come
with a cost so on the one hand you're
optimizing something which makes sense
as we've seen with all those
optimizations that we've seen but on the
other hand in some of those Corner cases
you leak some information and that can
be crucial and some of the mitigations
as we have seen we need to combine a lot
of them and we get a lot of performance
overhead and it costs so much
performance that we even lose more
performance than we actually gained with
the feature we implemented in the
firstand so that's also a huge problem
here here and because so many of the
defenses don't work or can be bypassed
we need we learn that we or we know that
the trans and execution attacks Will
Keep Us busy for a very long
time yeah
[Applause]
[Music]
[Applause]
[Music]
thanks
[Music]
thanks morit Mel da and cladio I think
we have about 10 minutes for
Q&A so please ask your
questions there's microphone number one
2 3 4 and five and I hope I see the
signal angel
yes so microphone number one please
thank you and thanks for the talk um you
hinted at some point that you can turn
off prediction so if you have a check
like if then else and uh want to get rid
of prediction there's something you
could do but you didn't say what so what
can you do to get rid of prediction
there so you mean in software yeah um so
you can introduce instructions that
where the processor won't speculate
across them uh because the processor
can't for instance undefined
instructions for instance CPU ID there
are instructions where the processor
goes be does not go beyond um also Intel
initially said uh you should use
something like lence because the
processor won't issue um memory loads
after an elence uh during speculative
execution similar with csdb on
arm okay thank
you cool microphone number two I think
yeah how much uh how much slower are the
processors after a software or a
hardware
patch round
about so that really depends on what
counter Meine you are enabling and what
workload you have on your computer so
for mown for example we have this Kaiser
batch also known as kpti on Linux and it
really depends on the workload you have
so on normal consumer PC where you use
some internet and office you get around
below 2% performance overhead so it's
it's fine but we have seen performance
overheads for uh computation heavy like
we have seen uh you worked with uh
Netflix with Brandon Greg yeah from
Netflix yeah and if you have a lot of
sis calls per second that's that's bad
and it also really depends on the CPU
that you have so if you have a newer
Intel CPU with bcid for instance you
also have a lower overhead and with
other CPUs and for instance uh because I
mentioned SVP uh that was recently
dropped it was reported that that did
cost about 20% in of performance so
that's quite a
lot thanks I think microphone number
four has a question yeah uh hi thanks
for the talk um I was wondering if you
well you only spoke about reading data
but what about writing data Maybe not in
the main memory but on the cache data
that would be used after by by the
kernel or another
process so there's one Spector attack
where you have like a speculative buffal
buffer overflow where you could
overwrite the return address and this is
will be executed speculatively so you
can do that but we haven't seen anything
where you persistently write the data
for rammer for instance you can flip a
bit in the dam and this bit flip will be
persistent or it can be persistent it
can yeah
yeah thanks thanks and I heard the
signal Angel has a question from the
interwebs are there any architectures
that aren't vulnerable to the attack
types you
mentioned yes so so for arm there are
some architectures which are not
vulnerable for instance to Melton some
of the custom cores of some companies
like the Samsung Core which they have
it's vulnerable for arm itself it's only
the
a73 I guess 75 uh 75 sorry and also some
older ones which do not have Branch
prediction at all so obviously they are
not affected yeah if you don't have if
the processor doesn't have the feature
uh usually it's very small processors
they all the embedded processors they
usually don't have Branch prediction or
out of order execution so they are fine
but there was a paper from uh um from
Yan B and he showed that even for a very
small uh microcontroller um if it has
some secure domain if there's some
security sense in the system there might
be uh meltdown type
effects thank you and microphone number
five please yes uh has any of these
attacks actually been seen in the
wild I don't know if we would be the
first to know that I think you would
have to ask that someone
else so we haven't heard of any attacks
in the
wild thanks and microphone number one
please um sorry if it's a stupid
question but you showed those uh circles
squares and stars and some slides uh
what what do those stand for well um if
it's a square it means that if it's full
then we can f Al argue okay this defense
works if it's empty then we thetically
argue it doesn't not work if it's a
start and it's something that we showed
in our in our re research paper um if
it's do we have the slide right
um if we have this symbol it just means
this is not applicable for for this
attack we we didn't want to put the
legend there because it's quite long
actually
but you can see the
paper uh you can see the paper and there
you will find the full
Legend thank you but empty is basically
bad and is
good and the last question I think is
for microphone number
one so hello thanks a lot for the talk
so I'm one of the rare people that run
exotic architectures and I'm running
power PC at home on a Talos 2 machine
and I was wondering if there is any uh
tool set to test the these
vulnerabilities on other architecture
and see if I am affected because I'm I'm
not sure if IBM is going to fund like
Intel any day I don't know generally IBM
processors are also affected we know
about the power8 uh for instance power 9
uh I think both power eight power n um
and they also have uh quite a heavy
performance loss if you enable the
mitigations um but so we ordered uh IBM
machines but we didn't receive them so
far so we couldn't run any tests on on
them uh but generally most of our
experiments are written mostly in C code
you would have to replace maybe a few
bits to adapt them to IBM but generally
the attack approach should be very
similar because the idea of the
underlying architecture is so
similar and well thanks for the answer I
will do this and publish rearch but um I
have another question and one question
please only one so uh the very last one
because we have two minutes left and I
think
the gentleman with a white code no he
doesn't want so microphone number two is
wiing yep thank you thanks for the talk
you showed a lot of new new variants of
the attack and as we stand it is not
under embargo right so um are the
mitigations against them currently
developed or we are just waiting for
proof of concept to
exploit I mean how many CPUs support
mpk yeah so the they're not real um
mitigations
being provided uh by by the vendors but
they say it's basically yeah it's so
simil just fix your software so that you
don't have ifs in your software for
example but so so it's more like um
users or developers should fix their
software because you could write
software for many of the variants in a
way that they can't be exploited anymore
with of course a performance impact and
we don't have real patches yet for them
it's also a bit of risk management
because where do you run untrusted code
Prim IL in your browser and JavaScript
and there we have site isolation um and
in other places so we are disabling the
stip patches by default now for for most
applications um so we are turning the
patches off because they cause too much
performance and the risk is not so high
currently probably this will change with
the first um real world exploits and
then people will say uh enable the
patches by default but uh that's how
security Works uh we never care about
security before something
happens
thanks and with this words we close this
talk a very warm
[Applause]
[Music]
Applause
[Music]
oh