So it was an interesting start to 2018 --
There was a lot of chatter on Twitter and other social networks about how
there was (sort of) a lot of patches
going into the Linux kernel was what I think started people noticing this -- and that perhaps there was a major
exploit about to be announced that would affect Linux perhaps and actually, as it turns out, Windows, Mac OS.
and other operating systems as well. The short of this is is that people at Google and various other universities, Rambus, and various other
institutions and so on have discovered a way that
any program can pretty much read data that it's not meant to be reading. That can be anything as simple as
reading a value past the end of an array even though the program is coded
to not let you do that -- which will then give you access to data that you shouldn't have in your program --
to up to, in the worst case, being able to read kernel memory
which is the operating system's memory where there's things like passwords and encryption keys stored -
to actually reading the whole memory of your computer in the worst case.
To make it worse, the really nasty thing about this one is it's not a problem in the software as such;
it's an actual problem with the way that modern CPUs are implemented, whether it's AMD,
Intel, ARM and so on - they've all said that in certain circumstances all their CPUs could be affected so it's a pretty
major thing which is going to require some rethinking perhaps of the way the CPUs are designed. The best comment
I've seen about this is the U.S.'s CERT - Computer Emergency Response Team's
article on this, which I've got open here.
It says CPU hardware implementations are vulnerable to
side channel attacks. These vulnerabilities are referred to as Meltdown and Spectre. And they say: "Solution: replace CPU hardware"
So it's pretty major
So the short of it is that you can now...
even though the OS is saying you can't [read memory] even though the program is saying you can't - you can read memory
that you shouldn't have access to, and then use that to exfiltrate data from the computer system that perhaps you shouldn't have access to.
According to Mozilla and Chrome and things there are ways that this can be done via JavaScript, say on a webpage, so you could
technically -- and I don't think it's been exploited yet -- but the real danger would be that you could go to a webpage
and it would copy out all your memory very slowly (must admit)
over the network and people would have access to things. It's not as bad as it sounds; there are
things that can be done in software that can patch and sort of mitigate the effects of this and stop it happening.
The downside of that is that they can have a significant
sort of speed performance hit.
Your programs will probably end up running slightly slower, slightly depends on what it's doing, how it's actually interacting with the operating system, and
so on but
as the CERT says, to really fix this it's going to need to require
redesigned CPUs.
[Sean]: The very big difference between this and other exploits
we've covered -- because every exploit seems to be the biggest thing since sliced bread -- the biggest thing is this the fact that it's hardware, right?
Yeah So this is not
something that can be directly patched in
with a new version of the software. or you can switch from Windows to Linux, or Linux to Windows to Mac OS, whatever it is, Free BSD...
FreeBSD, Dragonfly BSD, Open BSD -- whatever your favorite operating system of the month is.
This is an attack that is
[based] fundamentally in the way that the CPUs have been designed to work and
doesn't even require the operating system.
It can be done - if you can get the code to work
say, from a bit of JavaScript on a web page, and there are examples
that have been shown to do that.
[Sean]: As far as I see in the media, there's Spectre and there's Meltdown.
Are they completely different things then? Or is it just that they affect different devices? How does it work?
So they're basically all variants of the same techniques - a way of exploiting the design of a modern CPU
to access data that you shouldn't have access to. The best way to think about it
is that Spectre describes a sort of family of different techniques or
exploiting the way the CPU is designed to access data that you perhaps shouldn't have access to.
Meltdown is a specific instance of using one of those techniques
specifically to access the kernel's memory, and from that, to be able to get access to any sort of memory inside
the computer at that time. So they're all related and they sort of all work in a similar way.
We'll dive down in a minute and have a look.
In the paper that has been released describing the way the Spectre attacks work,
there's some demonstration code, which I've got here. It runs the same on Mac, Windows, Linux; you can take the same code
and bring it to different things. It's completely independent of the operating system; this is right down at the CPU level. What we've got is
a function which is accessing an array of 16 elements. So we have an array and it's called
array one
which has got 16 elements in it, and they are set to be 1, 2, 3, dot dot dot... up to
16. So accessing in this array... They're laid out in memory, and we've talked about that in previous videos.
This is then accessed by a variable X, which is used to index that array, but the program says if
X is less than 16, [then] access the array. If it isn't [less than 16], it's not going to access the array.
The program's been specifically written in a way so that they won't access values past the end of the array.
However,
by using the attacks described as what's been termed Spectre, then
you are able to still get the values. In this case,
the string that I've changed from the example to be "Hello Computerphile," and so if we compile this up and run it,
what we should see...
( just make it slightly bigger... )
... is we should see the message "Hello Computerphile" pop up.
So it's getting the data of various things, and we see here a "Hello Computerphile"
is popping up. If you go and grab the code, look at the paper -- it's sitting there at the back
Now this isn't
Anything too spectacular; it's one program accessing data inside its own program space.
Why is that an issue? Well the interesting thing is that what we've managed to do...
we've been able to do this by accessing a value that we shouldn't be able to access. This code, this if statement, should stop us
being able to access this past the end of this array. Yet as we can see there, the message
"Hello Computerphile" is appearing. This is a problem because this could actually be done from JavaScript on code
that's being downloaded from a webpage, and so one webpage will be able to pull things out of your web browser that
perhaps have been loaded from another webpage -- say, your bank details or something. So that's
one possible way that this could be exploited. The way that Spectre and
Meltdown work is that they take advantage of two features of a modern CPU -- the way they're designed and actually implemented.
So we've talked about how they're running our machine code, but underneath that's getting converted into the electronic circuits
which execute that and are firing them off
at the right times. Modern CPUs take advantage of two techniques, one of which is called out-of-order execution.
Basically, what this means is that the CPU will reorder the instructions --
Well, technically, reorder that micro-ops that the instructions get split up into, but that's going
into even more detail than we need
to find the best
way to execute them to keep everything going and running at the best speed. On top of this we get what's called speculative
evaluation, which basically means that the CPU is going to
execute code
even if it doesn't need to necessarily do that. The best example... If we go back to the code that we were running here...
This program has got a bit of code, and I've written it down here (the bits and we'll sort-of build up a bit)
which is accessing values from array 1
with an index of X. But before that, we check that our X is
less than the size of the array, and if it isn't, this code doesn't get executed. So what does Spectre need to do?
Spectre needs to do two things.
One: It needs to have this bit of code execute
even though it shouldn't, to try and get those values from our message out of there.
That's the first thing: it needs to get this bit of code to execute even though it shouldn't, and
Two: It needs to get the value returned from that out
and pass it so you can actually
extract that value -- to get that value that it was trying to read. So it's two things that it needs to do, and it can
do both of those things by exploiting the way that a modern CPU is designed.
Because a modern CPU
actually is designed
to sometimes execute code even though it doesn't need to.
Or rather, we have a technique called speculative evaluation, and what it will say is:
Okay, I am going to execute this code
because there's a very good chance that it might need to be done.
... But it might not, and if it doesn't, I'll undo what that code did and then execute the code
that should be done. An example where this might happen in
this code is if we didn't know the value of array one size --
we didn't know it was 16, so we hadn't actually got that value --
we'd have to go off to memory and get that value. If this had to go off to main memory rather than get it from
cache, it would take 200 times as long to
access it from main memory -- about 100 nanoseconds as opposed to half a nanosecond on a modern
sort-of typical modern CPU, so it'll take it a reasonably long time.
And so what the CPU will do while it's waiting for that value,
it'll make a prediction based on what's happened before -- based on the way this branch has happened before --
about whether it's going to execute this code or not.
And so it may well execute this code even though it doesn't need to, because it thinks it's going to do it.
In fact, there's ways that Spectre uses to
set that up so that that actually happens. The modern CPU will execute this anyway, and then throw the
result away. So how do we get the value out of it? Well actually if you look at the code
that's being used, it's not just getting the value from this.
It's actually then using that value to access another array, and it's actually multiplying this by 512.
Why is it doing that? Let's assume that this gets executed as well.
When it accesses this memory, it's going to
fetch (again we're talking about the cache) it's going to fetch in the whole cache line containing that thing into memory
and put it into the cache, so that will then get cached.
What that means is that the next time it's accessed, that
value is cached, so it'll be accessed very quickly, as opposed to very slowly - again about 200 times slower.
There's a way you can use the cache as a sort of covert channel to transfer information out based on whether something has been cached or not.
And as it turns out,
even though the result of this is thrown away,
because this then accessed the cache and brought that value into the cache line, it's not thrown away. So the cache actually
has that value in it.
So you can use speculative evaluation to cause this instruction to get executed and actually get the value from memory,
and then you can use the cache as a sort of covert channel to get that value,
or parts of that value out of this thing that's actually thrown away -- and you never actually see it --
[and turn it] into something that you can then extract. If you look at the rest of the code,
you'll see there're things where it's flushing the cache and timing how long
instructions take to run. So it's calling the function, and then it's looking at how long
instructions take to access to find out which value was cached --
which one was accessed quickly -- and that is based on
the value that was returned. So if you can find out which bit of memory was cached,
you can effectively use that as a proxy to find out what the value that was returned was,
even though the CPU threw that value away and so Spectre and
Meltdown all rely on the fact that the CPUs will sometimes do work
they don't have to, they will speculate and say well actually...
There's ways you can force that to actually be more likely to happen by setting things up in the right way
And if you read the paper [bitly link in description] you can see how that's done.
So it uses that to cause it, but normally that would be thrown away, but actually unfortunately
the way the modern CPUs are designed is that it's possible to set things up so they leave a footprint in the cache
about whether they accessed a value or not, and you can then
see what the value was returned. So it's sort of
clever way of extracting the values. They do it perhaps a bit at a time or a byte at a time.
What meltdown does is the same thing,
but it actually sort of
manages to get the data out of the kernel address space because of the way the caches are implemented and
the way that the protection checks are done; the speculative evaluation can sometimes happen
before the protection check happens because of the way the instructions can actually be reordered to make things work as best as possible.
So yeah, not good; probably need a new CPU.
[Sean]: Just reading between the lines: even though everybody's blowing up about Intel at the moment,
actually, the medium- to longer-term problem is all CPUs.
At the moment Intel has a problem because Meltdown specifically is a nasty effect,
and the mitigation will slow down the way computers work -- significantly, in some cases.
This technique of Spectre does work on other CPUs as well:
AMD, ARM, Intel have all said that in certain circumstances
there are ways that they're affected, so I suspect we will see a few more plays on this in the next few years.
By using this sort of idea of a superscalar approach we can actually have multiple instructions if they're in the right order --
they're sort of using different parts of the chips and so on -- we know multiple instructions execute at the same time
And then you can say well actually if we can do that
We can start to actually put say two ALU bits in which do the addition and so on we can have to add instructions?
providing they're separate