Best Analogy I've seen is as follows: "Imagine that you (i.e. a malicious process) want to know whether someone (i.e. a victim process) has checked out a particular library book. The library (i.e. the CPU) refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person of interest into the library whenever they return a book. You then ask the librarian for a copy of the books you want to know whether the person has checked out. If the librarian looks down and says "You are in luck, I have a copy right here!" then you know the person had checked out that book. If the librarian has to go look in the stacks and comes back 5 minutes later with the book, you know that the person didn't check out that book (this time). The way to make the library secure against this kind of attack is to require that all books be reshelved before they can be lent out again, unless the current borrower is requesting an extension. There are many other ways to use the behavior of the librarian and the time it takes to retrieve a book to figure out which books a person is reading." Not mine, don't know original source.
Analogies only ever make sense if you know what an analogy is. It is common in the internet generation for people to think of analogy as meaning 'a precise and accurate explanation'. That is incorrect.
But that doesn't explain how we can find out what's actually written in that book without checking it out ourselves (which the library wouldn't allow us to do).
+ZipplyZane it doesn't read the data from the cache. It uses timing to tell which of two memory locations is now in the cache, and can work out from that what the value of a secured memory location was
Thanks for getting a video out on this so quickly and pretending not to panic for the camera. Can we see the cut shots where Dr Bagley is shouting "WE'RE ALL DOOMED" and Brady is talking him down from the window ledge.
So this is extremely low-level and thus hard for my high-level programmer brain to fully grasp, but let me see if I got this straight: if the bounds of a loop are stored in memory, the CPU will try to optimize by running the code in the loop first while waiting for the bounds to be retrieved; if the bounds turn out to be such that the loop shouldn't have been run, the result of the code is discarded. But when a value is taken from memory and used as an array index, those values are cached to speed up future reads, and the cache is not cleared during that "memory undo" process. So if you try to access a memory location you shouldn't be able to inside a loop that "technically" terminates before that point, the access will still happen. And if you use that value as the index of an array you do have access to, it will be cached. At that point, the indexes of your valid array which are cached represent the values of the bytes you tried to access (the iterations of the loop beyond the slow-to-retrieve maximum bounds), so by timing how long it takes to retrieve those array entries, you can determine the values of the unauthorized bytes by interpreting the indexes of the fastest-loading array entries. Is that correct?
The second part definitely looks right. As for the first part: A single CPU core can do multiple things at the same time that use different portions of the hardware (e.g.: store/load at the same time as floating point math). The CPU's scheduler tries to keep all those portions occupied, by executing any upcoming instructions it can at the same time. If the code contains any kind of jump instruction (such as with an if statement, or a loop), it will guess which branch will be taken, and run instructions from that. On some hardware those instructions might result in loading memory to the L1 cache, before there has been an opportunity to check whether the running code is allowed to.
It looks like AMD hardware is only vulnerable to one of the three variants: the bounds check bypass. Some reports argue that this could be fixed by allowing the OS and the application code to disable speculative execution in certain circumstances. As I understand it the boundary check bypass only allows to exfiltrate data from the same process with the branch target injection being able to reach another process and the meltdown making vulnerable even the kernel. Intel and ARM hardware are afflicted by all three.
+Jameson Palmer - I've seen somebody post the line of code AMD submitted for incorporation into Linux, and it basically amounted to "if the CPU is made by AMD, don't do anything". I suspect they submitted something similar to Microsoft.
Its true. Unfortunately I will never switch back to AMD, that company let me down too many times. Anyway, its post update now and I cant tell the difference on my Intel i7 CPU!
@@scubasausage I'm wondering how you feel about Intel and AMD today? Not trying to be mean, I just wonder if perhaps 4 years of time changed your mind - and I'm not going to judge you if it didn't. Legit question - since while I'm an AMD fanboy (not a rabid one, I simply used to buy cheaper CPU's in the past, which often meant AMD and I didn't have any negative experiences with them), I'm more interested if people change their minds and how long does the damage from bad experiences (like for example the famously bad drivers for GPU's - which aren't bad anymore. Or at least not worse than NVIDIA, unless it's something very specialized) last. Regardless of whether you reply or not, I hope you're okay, since the last 2+ years have been tough. And I hope you have a great day/night.
This is the best analogy I could come up with for how Spectre works: Imagine you want to know the genre of book a particular person has checked out of the library. However, the library has strict privacy policies, and refuses to give you access to their records, only your own. What you do is reserve a book from every genre that the library carries, and then ask the librarian for the book you reserved of the same genre as the victim's book. The librarian, to save time, immediately begins fulfilling this request, even bringing said book up to the front desk, before finally realizing that the request itself breaches library privacy, and so refuses to return the book to you. Seems like you're out of luck, you don't know the genre of your reserved book behind the desk, so you haven't learned the genre of the victim's book. However, you now begin to request from the librarian every book you reserved one by one. Since these reserved books are properly a part of your records, the librarian happily obliges. For each book you note the librarian takes time to retrieve the book from inside the library, until one suspicious book is requested, which the librarian immediately hands you from behind the desk. That one suspicious book of course is the book requested from earlier, so with it identified and in your possession, you have successfully learned the genre of your victim's book. Now imagine repeating this process multiple times on the same victim using other qualities besides genre: like author, publisher, and so on. Each quality you learn about your victim's book allows you narrow down to the particular book your victim has checked out. Eventually, you will know for certain the identity of your victim's book, all by exploiting your hard working and naive librarian.
Interesting to note that all Raspberry Pi versions are invulnerable because their ARM chips either don't implement speculative branch evaluation (just branch prediction) or they don't implement it in a way that leaves traces in the cache.
People always care about performance/nuisance. People only care about security once they've already become a victim. See: everyone who lost data and said "i should use backups"
Right now, that's the bigger problem. These people aren't running untrusted code, so the actual bug isn't as big a deal to them. The bug is a bigger deal to regular users who run programs or web browsers, but the slowdown mostly affects servers and such.
Honestly, with the information we have right now, the exploit is pretty harmless. The only people with detailed knowledge about the exploit are the companies that are patching it. By the time it's used for malicious purposes, it will have already been patched by all the major operating systems. However, this patch comes at a major performance cost. The people in charge know how the exploit works, and there are fixes being made, so the exploit itself is rather harmless as of right now. However, all of this is at the cost of performance, and in the end, everybody is going to be taking a major performance hit, and that's why you see the headlines talking about performance much more than the exploit itself.
All the news has to report is that the intel "bug" is more severe / can affect performance. Instead they just say "INTELAND IS BURNING" "what do arms have to do with it anyway?"
Unless someone is coming up with such versions for AMD and others, it's still only Intelland that is burning. And Intel CEO Krzanich shall burn to a crisp if his sale of $24M of Intel shares AFTER getting notified about the problem and BEFORE public disclosure has anything to do with Meltdown.
It doesnt work on AMD CPUs when you work with the default Windows Settings of the CPU. AMD CPUs are only vulnerable when you have the eBPF-JIT extension activated.
I mean, most of the hardware that is most heavily effected by the performance hit (especially cloud servers and such) will cycle out of use in a few years.
I dont think so. I read in some paper that google purchases cheap, little bit old hardware in tons to run servers. I would imagine amazon doing the same. If you think about it its obvious, are you going to buy the latest hardware for a very high cost or are you going to buy old ones in large quantities that no one wants. Sure you would buy new fast hw, but not in the majority. So, it will affect clouds, meaning it affects the net as a whole.
Are you sure disingenuous is the word you're looking for? Mate, of course they need to redesign. But the consumer acquires these redesigns buy buying new hardware, as it's the whole design of the physical processor - not just a specific part of it- that's affected by this inherent physical flaw.
Well the news have been out for a while among academics, only recently it blew up on the press and popular sites like Reddit. In fact, the vulnerability was discovered in the middle of 2017.
The exploit was discovered months ago, and only disclosed to the general public recently. IDK if computerphile got insider info, but there was plenty of time to properly document the issue, so at this point it's actually pretty easy to read up on what's going on.
I don’t think they can even if they wanted to, because it would be about educating the actual hack and that violates TH-cam policy and terms of service.
If you don't mind spending the time, you can read the article. I know video is easier to follow, but if you really want to learn more in depth I think the article is the best source.
Fantastic job explaining these exploits! Probably the cleanest and to-the-point description I've seen on TH-cam so far. You know you're doing good when your viewers can use you as a security news source. 😉
"Meltdown" (aka "Variant 3") is an Intel issue. Yes, Intel very much wants to confuse the matter, but make no mistake, that's their fuckup. (**see comments)
+Random2 regular people a). wouldn't notice a 10% performance degradation, b). it does not affect typical desktop workloads (Office, gaming, web) so people that use ARM CPUs really won't care much if at all OTOH, high performance people have already spent millions of dollars on CPUs alone and now it turns out they are 10 or 30% slower? They _will_ care and they do have the money to spend on lawyers.
I don't think they are at serious risk of a lawsuit. This is a bug/problem in the hardware, and can be fully explained by human error. The only way I can see this turning in a lawsuit is if somebody can prove that Intel had malicious intent, and that the exploit was put in on purpose. The only other way would be to claim that Intel had purposefully hidden the exploit, but Intel will probably claim that it was done to hide the information from other people with malicious intent.
Whoa whoa whoa! First off, all I said is that it affects other processors. Nothing more than that. And it does. This is a fact. I said nothing about user's perception of it nor who will be affected. This is not, as the original poster said, "an intel fuckup". It is a design choice by the majority of the industry. It's either a fuckup by the majority of the industry, or a fuckup by none.
What I find surprising about this is that it took this long to discover this flaw. I don’t know much programming, though I do know some, and even less about implementations details and hacks like this. But even I know that CPUs have implemented speculative execution for a long time now. The methods described here seem to me pretty amazingly simple. It surprises me that no one thought of trying to exploit this before now!
James Bond asks his mate "Mr CPU" to go wait for him at a bar. The Criminal Mastermind named "Meltdown" goes into the bar and says "I have a drink for Mr Bond here, anyone want it?" All in the bar take a while, looking around and asking "are you James Bond?", but Mr CPU instantly answers "No, he is not here", then James bond walks in...
Alexey Zaytsev I mean, he does work for Apple as a software developer or something like that. Rockets are his hobby but computers are his actual job. I agree though, I liked his explanation better.
To be fair, the man being interviewed does not run his own TH-cam channel and command an audience with a range of different ages and degrees of education, and tailor and present everything in a highly accessible and entertaining fashion. This a computer scientist sitting at his desk, and was asked to talk about the highly technical points of serious low-level exploits. I am not sure why you would expect the classic nerds that live under rocks to be Scott Manleys with 650,000 subs. People like this generally live in offices and computer labs, away from human interaction, and quietly make the world work.
This glosses over the most interesting part. :) The covert channel is timing how long it takes to read something, which is affected by what is in cache. Speculative execution can change what is cached and so allows the covert channel to exist, in combination with branch prediction making the wrong prediction. The branch prediction can be trained in a few ways, one of which involves the realization that the branching decision is remembered not by instruction location but by only some low bits of the branching instruction. The neat part is that the speculative execution can include a second lookup based on the first value fetched. Multiplication by the cache line size (the size of the chunk of memory that will be read when it is loaded in to cache), and then using that as a second lookup offset, fetches a unique cache line for each original value. This is the trick that allows the original data to be read (by then timing the reads of each possible offset).
Always look forward to watching Computerfile's break down of the newest and greatest security vunribility. Another great video guys! PS: from what I have gathered, it's a vunribility where all the correct things have to be under the exact right circumstances for it to occur. I have yet to see any real real-world examples or instances where this attack has or can be used besides some whitepaper's example code. In other words, I'm not phased by this nor do I care about the risks it brings.
It's not easy to explain such a thing without going into details too deeply, yet staying meaningful. I think made a great job, as always, here in computerphile. (The cache access time could have been a bit more emphasized, though.) But PLEASE, PLEASE USE A TRIPOD! It would be such a quality leap for these videos!
The worst part about all of this is it took independent researchers to find this just by chance. Various security agencies have well-funded branches that find bugs like this regularly around the clock all day every day of the year from full hardware exploits to firmware exploits to OS exploits. Hardware ones are less frequent, but still happen especially against embedded devices that don't change regularly. Some older devices are still connected to the internet as well, which is much worse. That includes some hardware that literally controls the backbone of the internet in some regions, some is still ancient and still used simply because it is reliable and If It Works Don't Fix It. (same reason we are still stuck with IPv4!) It's also a hard job to deal with in space hardware because it's feature-progression is considerably slower than main-line hardware. Biggest reason being the new hotness in CPU hardware generally leads to literal hotness in that they run hotter. Much much hotter. (especially branch prediction, which is the parent architectural fault involved in both of these bugs) This is very bad for space because it is stupidly hard to cool things there due to the lack of medium to move the heat in to because space is inert. Only way to get heat away is radiative, which is extremely slow. So you end up needing these complex cryo-cooling systems in CPU-heavy satellites, which limits their maximum operation time quite considerably and increases complexity. (and potential for failure) So this can lead to issues with space hardware if any bugs are found in them as well. All it could take is one hardware exploit to kill the GPS framework and bring modern globalized society to a standstill. (and the smartphone generation) Given how much money gets pumped in to exploitation branches of security agencies, they likely already know a few that could cripple society-wide services. Sometimes if they are really severe, they even announce them. However relationships in the security industry are broken over the whole blanket-spying stuff done by Five Eyes and the like. Many people are taking advantage of it by leaving security agencies and forming their own companies to make some cash. NSA lost loads of people.
As bad as this exploit is, i'm not too worried. As far as the regular folks are concerned, I find it far more likely that they are going to have random other software related exploits whether it be trojan's, keyloggers, phising scams. Plenty of other things for them to fall for, rather than getting a more complicated program on their computer which does this slow data extraction which may or may not be useful, given that the implementer has to know what they are looking for before they can even make use of data. This issue should likely be quite simple to fix for Javascript/code from the web, as the code is compiled by the browser, you could just alter the JS compilation/VM process to break any cache coherence thus resulting in speculative execution not working for higher level code.
MishMash The big problems, that make the industry scared shitless over this, isn't browser exploits. It is the fact that these exploits break virtual _machine_ isolation. You can go onto almost any cloud computing provider, rent a computing instance and run this exploit to read data from other virtual machines running on the same host. This is insanely serious, and one cannot overstate the importance of this class of exploits. And what makes Intel such a loser in this scenario is that the only mitigations short of replacing the actual CPUs is using a technique for addressing virtual memory between os kernel and userland program that will seriously degrade system performance. AMD currently isn't affected by that part of the exploits which means they can still run at full tilt, even with mitigation measures in place.
Yeah this is true, I hadn't really considered the implications for shared server resources. Though it is still equally quite hard and slow to actually extract data. Partially because you won't necessarily know where other applications hold this data. On the plus side, there are a number of things you can do at the software level to protect the data. For example, there are schemes of encryptions that enable you to manipulate/work with data however ensure that when it is written to RAM, the value stored in RAM is always the encrypted version, or atleast an unusable form of the data. (This would mean any speculative execution that pulls the data into the cache would only pull in meaningless data. Data that exists in the cache that you are working with would exist in its raw form whilst being manipulated, but after this, you can evict it from the cache so that even if the data was pulled back in during an undesired scenario, it wouldn't be useful.) It's definitely a big issue, however it still remains quite impractical to make use of in a real-world scenario, when we are dealing with huge amounts of memory.
The processors have still been shrinking, we're not quite at the end of it yet. Also we'll begin building chip structure vertically as well, allowing for immense increases in performance.
Good high-level explanation, I encourage people interested to read the papers published and do some research about branch prediction. For starters, Tomasulo's algorithm was one of the first OOO execution designs that many processors are still based off of. It's old, so it's easier to comprehend then today's massively complicated schemes, but will still give you a taste of what happens at the h/w level.
I like how; while under development, the patch that was applied by Linux devs was given the name "Forcefully Unmap Complete Kernel With Interrupt Trampolines", it was changed for the actual release of the patch because of the same reason as why I like the name... spell out the first letter of each word xD
I seen this coming from the moment I began experimenting with parallel programming techniques. Having developed a lot of creative uses of Semaphores to get around the pitfalls of out of order execution, I will be incredibly happy when we start to see processors that don't pretend to know better than the programmer what order their instructions should be executed. I should never have to suspect memory barriers I drop into my code aren't actually doing anything but you would be surprised just how often modern processors completely ignore their presence.
The title needs to be better. Before I knew what spectre & meltdown were I had no desire to watch this video. Then I watched The WAN Show and now I want to.
Wow, very fast content reaction to current "Computerphile" topics. Great! By the way: does CERT list hardware which is considered "secure" in terms of Spectre and Meltdown?
So, the way to solve this would be to throw out cache lines that were read in by speculatively executed code, right? Does the branch predictor set any flags that could be used as a trigger for an interrupt handling such a thing? So long as you are not using a real-time operating system the slight delay should be virtually undetectable. If the CPU had to be redesigned, the branch predictor may simply need his own dedicated cache lines for backup storage.
TH-cam thought I was going to watch this video, but I looked at how long it was and decided not to. Instead, I watched a Numberphile video really carefully, and now I know everything that's said in this video. I don't think that's supposed to happen.
4:48 Dr Bagley is creating an 'off by one' error. In most languages that array would contain 17 items, not 16. Thanks for the buffer overflow, dr Heartbleed.
Steve Bagley Thumbs up for mentioning the BSDs. Their developers haven't been a part of the embargoed information, even though they run a pretty significant part of the Internet's backends...
Is the out of order execution order determined by hardware? It sounds like a software kind of thing to calculate that. And if that is solved then the security checks will be done in time.
I followed everything up to getting the data out of the cache... How do you get the data once it is in the cache? It could be anywhere in the cache especially once you go far beyond the array end. Even if you knew the exact cache line, how would you retrieve it in user mode anyway?
One question, though: how does the malware/hacker know what it/he/she's looking at? -ok, things can be pulled out of memory at the CPU level, but as far as I understand it, it's another three levels (kernel, API and application) before that data is human readable and in context. Good luck figuring out I'm watching a Heartstone commercial on TH-cam. Also... execution speed seems quite slow, won't locations be overwritten with something else before the program has run it's cycle, further complicating matters?
I've been reading very mixed opinions on the likely effect on Intel CPU performance. I'd love to hear a detailed and unbiased explanation of this. Also, does this mean consumers should avoid buying new computers until the next generation of redesigned CPUs?
Question: Since most computers from atleast the early 90s - present have this flaw with the new security issue, would it be possible (if having an old development unit for a videogame system or something (say N64) or a dev cartridge) would it be theoretically possible with the right tools (and the Meltdown/Spectre flaws) to obtain source code/ documentation on videogames in which the source code was thought to be locked down under the aformentioned cartridge/cpu ?
Is there a way to disable the cache entirely in modern CPUs? Perhaps from the BIOS? That might be a temporary fix, despite the massive slowdown it may cause
Thank you! Have been wondering how this actually worked, media have been pretty universally poor in how they're covering this (as usual). Then again it's pretty difficult to explain to the layman apparently, I'm not far from that but I think I just about get it. Does the 'patch' simply hinder speculative evaluation?
I understand how you can read the prefetched piece of memory that exceeds the array size check, but a prefetcher doesn't prefetch the entire memory. How is it that you can read everything instead of just the first bits after the end of your own program space?
Is the party over for crypto with Meltdown and Spectre around? I am feeling bummed-out because I deeply wanted crypto to be my new career. I do have a ledger, but wanted to speculate on ICO's and low-cap crypto's also. I was planning on using MyEtherWallet for erc-20 tokens. Thoughts?
Thanks for this interresting and easy-to-understand explanation of the exploit. However, one thing remains unclear to me: This is a bug in the hardware, so how can it be patched in the OS?
Is this severe enough for sandboxed instances to be able to access resources it shouldn't? To me it seems to be possible for the vulnerability to grant access to code outside of that sandboxed state. If so, this would be a very bad issue indeed.
There has been talk about this for some time (for years), so I'm not sure why this is suddenly seen as a huge problem now. Though I gather nobody knew exactly how to exploit this vulnerability before, and that someone finally decided to make a proof-of-concept.
the one thing i dont really get is, why it is an hardware issue. I mean how can speculative branch evaluation, or rather the logic behind it be implemented in hardware. Or is it?
So does speculative evaluation just have to go away? Is this a fundamental problem with the idea of speculative evaluation or a specific implementation of it? Sucks if a whole idea for fast computing has to go away. :-(
Could the CPU architecture be programmed so that coders have more control over what is loaded into cache? I mean indexing in cache is useful but could we have say a keyword in languages that says "this data shouldn't be cached". Maybe somewhere in memory would be reserved specifically for types of important data that should never be cached? I know it would cause performance issues if this was frequently used but is this a sort of viable solution (I realise regular RAM access is waaay slower than even L3 cache)
Wow. There's something like 20 years worth of processors which are vulnerable to this family of exploits. Wasn't the Pentium Pro Intel's first out-of-order processor? That came out in the mid-to-late 1990s, so we're in pretty hot water with this lot.
![[LIVE] : ONE ลุมพินี 85 | คู่เอก "ยอดเหล็กเพชร vs ผึ้งหลวง"](http://i.ytimg.com/vi/Qq_19bnnxEo/mqdefault.jpg)
Best Analogy I've seen is as follows:
"Imagine that you (i.e. a malicious process) want to know whether someone (i.e. a victim process) has checked out a particular library book. The library (i.e. the CPU) refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out.
What you do is follow the person of interest into the library whenever they return a book. You then ask the librarian for a copy of the books you want to know whether the person has checked out. If the librarian looks down and says "You are in luck, I have a copy right here!" then you know the person had checked out that book. If the librarian has to go look in the stacks and comes back 5 minutes later with the book, you know that the person didn't check out that book (this time).
The way to make the library secure against this kind of attack is to require that all books be reshelved before they can be lent out again, unless the current borrower is requesting an extension.
There are many other ways to use the behavior of the librarian and the time it takes to retrieve a book to figure out which books a person is reading."
Not mine, don't know original source.
47 people didn't read this, if they did they would know that it makes no sense.
Analogies only ever make sense if you know what an analogy is.
It is common in the internet generation for people to think of analogy as meaning 'a precise and accurate explanation'.
That is incorrect.
Thanks for explaining how a timing based attack works. I felt the explanation here didn't really explain how they get the data out of the cache.
But that doesn't explain how we can find out what's actually written in that book without checking it out ourselves (which the library wouldn't allow us to do).
+ZipplyZane it doesn't read the data from the cache. It uses timing to tell which of two memory locations is now in the cache, and can work out from that what the value of a secured memory location was
Thanks for getting a video out on this so quickly and pretending not to panic for the camera.
Can we see the cut shots where Dr Bagley is shouting "WE'RE ALL DOOMED" and Brady is talking him down from the window ledge.
And Pound is putting both S&M on all the computers in the Enlgish countryside
So this is extremely low-level and thus hard for my high-level programmer brain to fully grasp, but let me see if I got this straight: if the bounds of a loop are stored in memory, the CPU will try to optimize by running the code in the loop first while waiting for the bounds to be retrieved; if the bounds turn out to be such that the loop shouldn't have been run, the result of the code is discarded. But when a value is taken from memory and used as an array index, those values are cached to speed up future reads, and the cache is not cleared during that "memory undo" process.
So if you try to access a memory location you shouldn't be able to inside a loop that "technically" terminates before that point, the access will still happen. And if you use that value as the index of an array you do have access to, it will be cached. At that point, the indexes of your valid array which are cached represent the values of the bytes you tried to access (the iterations of the loop beyond the slow-to-retrieve maximum bounds), so by timing how long it takes to retrieve those array entries, you can determine the values of the unauthorized bytes by interpreting the indexes of the fastest-loading array entries.
Is that correct?
IceMetalPunk seems correct
This is what my brain needed. You seem to at least have grasped it better than I did.
The second part definitely looks right.
As for the first part: A single CPU core can do multiple things at the same time that use different portions of the hardware (e.g.: store/load at the same time as floating point math). The CPU's scheduler tries to keep all those portions occupied, by executing any upcoming instructions it can at the same time. If the code contains any kind of jump instruction (such as with an if statement, or a loop), it will guess which branch will be taken, and run instructions from that. On some hardware those instructions might result in loading memory to the L1 cache, before there has been an opportunity to check whether the running code is allowed to.
IceMetalPunk dude ty for this
RC-1290 Modern CPUs have sufficient pipeline processing to speculatively execute both branches of an IF statement. That is where the problem began.
I knew you’d post a video about it quickly! This is why I’m a happy subscriber
The real scandal is that Intel was notified about this over 6 months ago and their CEO dumped millions in stock before announcing this exploit.
I read that other chip makers also have these bugs, including their largest competitor AMD.
well the ceo was smart
In the realm of money, no one is a saint.
@@wnsjimbo2863 well he had insider knowledge and this is a crime
Not just dump but also buy options etc
It looks like AMD hardware is only vulnerable to one of the three variants: the bounds check bypass. Some reports argue that this could be fixed by allowing the OS and the application code to disable speculative execution in certain circumstances. As I understand it the boundary check bypass only allows to exfiltrate data from the same process with the branch target injection being able to reach another process and the meltdown making vulnerable even the kernel. Intel and ARM hardware are afflicted by all three.
AMD are helping to set the code so it only runs the right fix on Intel, and the other fixes on AMD. I've not yet seen how or when this is applied.
+Jameson Palmer - I've seen somebody post the line of code AMD submitted for incorporation into Linux, and it basically amounted to "if the CPU is made by AMD, don't do anything". I suspect they submitted something similar to Microsoft.
amd is afflicted only by level 1 spectre, spectre level 2 is near no risk which mean they have to be physicaly on your computer
Its true. Unfortunately I will never switch back to AMD, that company let me down too many times. Anyway, its post update now and I cant tell the difference on my Intel i7 CPU!
@@scubasausage I'm wondering how you feel about Intel and AMD today?
Not trying to be mean, I just wonder if perhaps 4 years of time changed your mind - and I'm not going to judge you if it didn't. Legit question - since while I'm an AMD fanboy (not a rabid one, I simply used to buy cheaper CPU's in the past, which often meant AMD and I didn't have any negative experiences with them), I'm more interested if people change their minds and how long does the damage from bad experiences (like for example the famously bad drivers for GPU's - which aren't bad anymore. Or at least not worse than NVIDIA, unless it's something very specialized) last.
Regardless of whether you reply or not, I hope you're okay, since the last 2+ years have been tough. And I hope you have a great day/night.
Summary of the exploit: "Cache me outside... how bout dat?"
thanks
lol thank you
AHaha, Nice :D
You sir win at the internet
lol take your like and go
replace cpu? with what, a rock?
only way to be safe probably
there are no alternatives, until they redesign whole cpu and manufacture it :D
Buy an FPGA and make your own CPU.
yondaime500 or use a toilet!
Logic gates and a few million breadboards.
This is the best analogy I could come up with for how Spectre works:
Imagine you want to know the genre of book a particular person has checked out of the library. However, the library has strict privacy policies, and refuses to give you access to their records, only your own.
What you do is reserve a book from every genre that the library carries, and then ask the librarian for the book you reserved of the same genre as the victim's book. The librarian, to save time, immediately begins fulfilling this request, even bringing said book up to the front desk, before finally realizing that the request itself breaches library privacy, and so refuses to return the book to you. Seems like you're out of luck, you don't know the genre of your reserved book behind the desk, so you haven't learned the genre of the victim's book.
However, you now begin to request from the librarian every book you reserved one by one. Since these reserved books are properly a part of your records, the librarian happily obliges. For each book you note the librarian takes time to retrieve the book from inside the library, until one suspicious book is requested, which the librarian immediately hands you from behind the desk. That one suspicious book of course is the book requested from earlier, so with it identified and in your possession, you have successfully learned the genre of your victim's book.
Now imagine repeating this process multiple times on the same victim using other qualities besides genre: like author, publisher, and so on. Each quality you learn about your victim's book allows you narrow down to the particular book your victim has checked out. Eventually, you will know for certain the identity of your victim's book, all by exploiting your hard working and naive librarian.
Interesting to note that all Raspberry Pi versions are invulnerable because their ARM chips either don't implement speculative branch evaluation (just branch prediction) or they don't implement it in a way that leaves traces in the cache.
Invulnerable to meltdown because the cortex a53 doesnt have out of order execution.
Literally checked this channel for this last night! You guys are awesome! Keep up the great work!
What infuriates me is that the majority of the headlines are about the slowdown, and not about the vulnerability itself -.-
People always care about performance/nuisance. People only care about security once they've already become a victim. See: everyone who lost data and said "i should use backups"
Right now, that's the bigger problem. These people aren't running untrusted code, so the actual bug isn't as big a deal to them. The bug is a bigger deal to regular users who run programs or web browsers, but the slowdown mostly affects servers and such.
Honestly, with the information we have right now, the exploit is pretty harmless. The only people with detailed knowledge about the exploit are the companies that are patching it. By the time it's used for malicious purposes, it will have already been patched by all the major operating systems. However, this patch comes at a major performance cost. The people in charge know how the exploit works, and there are fixes being made, so the exploit itself is rather harmless as of right now. However, all of this is at the cost of performance, and in the end, everybody is going to be taking a major performance hit, and that's why you see the headlines talking about performance much more than the exploit itself.
Bc they think the patch fixed it. Idiots
I believe resource heavy situations like gaming etc are affected also but from memory I think bitcoin mining isnt somehow
Finally someone with knowledge of computer engineering addresses the issue and also points that Meltdown affects Intel specifically.
All the news has to report is that the intel "bug" is more severe / can affect performance. Instead they just say "INTELAND IS BURNING" "what do arms have to do with it anyway?"
Unless someone is coming up with such versions for AMD and others, it's still only Intelland that is burning. And Intel CEO Krzanich shall burn to a crisp if his sale of $24M of Intel shares AFTER getting notified about the problem and BEFORE public disclosure has anything to do with Meltdown.
Yes it does. Insider trading at its finest.
It doesnt work on AMD CPUs when you work with the default Windows Settings of the CPU.
AMD CPUs are only vulnerable when you have the eBPF-JIT extension activated.
didn't he explained very clearly that it is NOT intel specific??? Also ARM and AMD CPU's are affected.
"Replace CPU hardware" *Straight face*
Laughed out loud
I mean, most of the hardware that is most heavily effected by the performance hit (especially cloud servers and such) will cycle out of use in a few years.
I dont think so. I read in some paper that google purchases cheap, little bit old hardware in tons to run servers. I would imagine amazon doing the same. If you think about it its obvious, are you going to buy the latest hardware for a very high cost or are you going to buy old ones in large quantities that no one wants. Sure you would buy new fast hw, but not in the majority. So, it will affect clouds, meaning it affects the net as a whole.
when i heard this i laughed so hard because i just spent £150 on my cpu ..... -_- FML
I got a chuckle out of that.
However replacing is a little disingenuous. Redesigning is what we need. Still would have chuckled at that
Are you sure disingenuous is the word you're looking for? Mate, of course they need to redesign. But the consumer acquires these redesigns buy buying new hardware, as it's the whole design of the physical processor - not just a specific part of it-
that's affected by this inherent physical flaw.
That was fast, I thought it would take you a week or so to discuss it.
Only if you don't know what you are talking about :-D.
Well the news have been out for a while among academics, only recently it blew up on the press and popular sites like Reddit.
In fact, the vulnerability was discovered in the middle of 2017.
The exploit was discovered months ago, and only disclosed to the general public recently.
IDK if computerphile got insider info, but there was plenty of time to properly document the issue, so at this point it's actually pretty easy to read up on what's going on.
Scott Manley talked in depth about it not even 24 hours with an example Javascript code to run linked in the release if I recall.
It would be awsome if you could make more in depth videos, not only on this topic, maybe including the code explanation
I had the same though. "Please, explain the code behind you, even in hour long, detailed video." I would watch it, for sure.
I don’t think they can even if they wanted to, because it would be about educating the actual hack and that violates TH-cam policy and terms of service.
If you don't mind spending the time, you can read the article. I know video is easier to follow, but if you really want to learn more in depth I think the article is the best source.
Scott Manley did a video explaining it better (in my opinion). Check it out, I could understand everything and he even goes more in depth.
Fantastic job explaining these exploits! Probably the cleanest and to-the-point description I've seen on TH-cam so far. You know you're doing good when your viewers can use you as a security news source. 😉
"Meltdown" (aka "Variant 3") is an Intel issue. Yes, Intel very much wants to confuse the matter, but make no mistake, that's their fuckup. (**see comments)
they are in store for a multi billion dollar class action lawsuit, of course they're trying to confuse the matter and shift blame
It also affects ARM and powerpc (apple) as well, does it not? It is not just Intel...
+Random2 regular people a). wouldn't notice a 10% performance degradation, b). it does not affect typical desktop workloads (Office, gaming, web)
so people that use ARM CPUs really won't care much if at all
OTOH, high performance people have already spent millions of dollars on CPUs alone and now it turns out they are 10 or 30% slower? They _will_ care and they do have the money to spend on lawyers.
I don't think they are at serious risk of a lawsuit. This is a bug/problem in the hardware, and can be fully explained by human error. The only way I can see this turning in a lawsuit is if somebody can prove that Intel had malicious intent, and that the exploit was put in on purpose. The only other way would be to claim that Intel had purposefully hidden the exploit, but Intel will probably claim that it was done to hide the information from other people with malicious intent.
Whoa whoa whoa! First off, all I said is that it affects other processors. Nothing more than that. And it does. This is a fact. I said nothing about user's perception of it nor who will be affected. This is not, as the original poster said, "an intel fuckup". It is a design choice by the majority of the industry. It's either a fuckup by the majority of the industry, or a fuckup by none.
Finally, a tech channel for serious IT people! This is my new goto source for serious vulnerbilities and game-changing tech.
Great video. Can always count on Computerphile to provide a detailed yet concise explanation which is easy to understand
Best computer science channel on TH-cam! 🤓👍
Wait! Are you saying my 486DX is unaffected by this? PHEW! And there I was, thinking I would need to upgrade my CPU.
SGS-Thomson ST5x86 master race.
Hey do you sell your 486DX? Im still on an SX and would really enjoy some floating point units. *__*
AMD486 guy here
What I find surprising about this is that it took this long to discover this flaw. I don’t know much programming, though I do know some, and even less about implementations details and hacks like this. But even I know that CPUs have implemented speculative execution for a long time now. The methods described here seem to me pretty amazingly simple. It surprises me that no one thought of trying to exploit this before now!
James Bond asks his mate "Mr CPU" to go wait for him at a bar. The Criminal Mastermind named "Meltdown" goes into the bar and says "I have a drink for Mr Bond here, anyone want it?" All in the bar take a while, looking around and asking "are you James Bond?", but Mr CPU instantly answers "No, he is not here", then James bond walks in...
Somehow Scott Manley, the guy who plays Kerbal Space Program, had a much clearer and more detailed explanation that the Computerphile channel.
Alexey Zaytsev I mean, he does work for Apple as a software developer or something like that. Rockets are his hobby but computers are his actual job. I agree though, I liked his explanation better.
Hello it's Scott Manley here and you just read this comment in my voice.
Nice. Didn't know a part of his viewerbase spills over to this channel.
To be fair, the man being interviewed does not run his own TH-cam channel and command an audience with a range of different ages and degrees of education, and tailor and present everything in a highly accessible and entertaining fashion.
This a computer scientist sitting at his desk, and was asked to talk about the highly technical points of serious low-level exploits. I am not sure why you would expect the classic nerds that live under rocks to be Scott Manleys with 650,000 subs. People like this generally live in offices and computer labs, away from human interaction, and quietly make the world work.
This glosses over the most interesting part. :) The covert channel is timing how long it takes to read something, which is affected by what is in cache. Speculative execution can change what is cached and so allows the covert channel to exist, in combination with branch prediction making the wrong prediction. The branch prediction can be trained in a few ways, one of which involves the realization that the branching decision is remembered not by instruction location but by only some low bits of the branching instruction.
The neat part is that the speculative execution can include a second lookup based on the first value fetched. Multiplication by the cache line size (the size of the chunk of memory that will be read when it is loaded in to cache), and then using that as a second lookup offset, fetches a unique cache line for each original value. This is the trick that allows the original data to be read (by then timing the reads of each possible offset).
Best under fiveteen minutes video on that topic i have seen do far
Always look forward to watching Computerfile's break down of the newest and greatest security vunribility. Another great video guys!
PS: from what I have gathered, it's a vunribility where all the correct things have to be under the exact right circumstances for it to occur. I have yet to see any real real-world examples or instances where this attack has or can be used besides some whitepaper's example code. In other words, I'm not phased by this nor do I care about the risks it brings.
Great explanation, thanks!
6:55 is when any details Beyond a typical layperson news article start
It's not easy to explain such a thing without going into details too deeply, yet staying meaningful. I think made a great job, as always, here in computerphile. (The cache access time could have been a bit more emphasized, though.) But PLEASE, PLEASE USE A TRIPOD! It would be such a quality leap for these videos!
All your systems are belong to us.
Secret nyce mim
What you say?
Take off every 'ZIG'!!
:D
ok
The worst part about all of this is it took independent researchers to find this just by chance.
Various security agencies have well-funded branches that find bugs like this regularly around the clock all day every day of the year from full hardware exploits to firmware exploits to OS exploits.
Hardware ones are less frequent, but still happen especially against embedded devices that don't change regularly. Some older devices are still connected to the internet as well, which is much worse. That includes some hardware that literally controls the backbone of the internet in some regions, some is still ancient and still used simply because it is reliable and If It Works Don't Fix It. (same reason we are still stuck with IPv4!)
It's also a hard job to deal with in space hardware because it's feature-progression is considerably slower than main-line hardware. Biggest reason being the new hotness in CPU hardware generally leads to literal hotness in that they run hotter. Much much hotter. (especially branch prediction, which is the parent architectural fault involved in both of these bugs)
This is very bad for space because it is stupidly hard to cool things there due to the lack of medium to move the heat in to because space is inert. Only way to get heat away is radiative, which is extremely slow. So you end up needing these complex cryo-cooling systems in CPU-heavy satellites, which limits their maximum operation time quite considerably and increases complexity. (and potential for failure)
So this can lead to issues with space hardware if any bugs are found in them as well.
All it could take is one hardware exploit to kill the GPS framework and bring modern globalized society to a standstill. (and the smartphone generation)
Given how much money gets pumped in to exploitation branches of security agencies, they likely already know a few that could cripple society-wide services.
Sometimes if they are really severe, they even announce them. However relationships in the security industry are broken over the whole blanket-spying stuff done by Five Eyes and the like. Many people are taking advantage of it by leaving security agencies and forming their own companies to make some cash. NSA lost loads of people.
"Replace CPU-" *quickly pauses, heart sinks, sense of impending doom looms over me* Please god no...
Timely
As bad as this exploit is, i'm not too worried. As far as the regular folks are concerned, I find it far more likely that they are going to have random other software related exploits whether it be trojan's, keyloggers, phising scams. Plenty of other things for them to fall for, rather than getting a more complicated program on their computer which does this slow data extraction which may or may not be useful, given that the implementer has to know what they are looking for before they can even make use of data.
This issue should likely be quite simple to fix for Javascript/code from the web, as the code is compiled by the browser, you could just alter the JS compilation/VM process to break any cache coherence thus resulting in speculative execution not working for higher level code.
MishMash The big problems, that make the industry scared shitless over this, isn't browser exploits. It is the fact that these exploits break virtual _machine_ isolation. You can go onto almost any cloud computing provider, rent a computing instance and run this exploit to read data from other virtual machines running on the same host. This is insanely serious, and one cannot overstate the importance of this class of exploits. And what makes Intel such a loser in this scenario is that the only mitigations short of replacing the actual CPUs is using a technique for addressing virtual memory between os kernel and userland program that will seriously degrade system performance. AMD currently isn't affected by that part of the exploits which means they can still run at full tilt, even with mitigation measures in place.
Yeah this is true, I hadn't really considered the implications for shared server resources. Though it is still equally quite hard and slow to actually extract data. Partially because you won't necessarily know where other applications hold this data.
On the plus side, there are a number of things you can do at the software level to protect the data. For example, there are schemes of encryptions that enable you to manipulate/work with data however ensure that when it is written to RAM, the value stored in RAM is always the encrypted version, or atleast an unusable form of the data. (This would mean any speculative execution that pulls the data into the cache would only pull in meaningless data. Data that exists in the cache that you are working with would exist in its raw form whilst being manipulated, but after this, you can evict it from the cache so that even if the data was pulled back in during an undesired scenario, it wouldn't be useful.)
It's definitely a big issue, however it still remains quite impractical to make use of in a real-world scenario, when we are dealing with huge amounts of memory.
After the end of Moore's Law, it turns out there's no such thing as a free lunch.
LET US BELIEVE YOU MONSTER
Seems like everyone gets Moore's Law wrong. Ugh.
The processors have still been shrinking, we're not quite at the end of it yet. Also we'll begin building chip structure vertically as well, allowing for immense increases in performance.
Yeah and how exactly are you planning to dissipate the heat from these 3D circuits?
Watercooled with nanotubes.
Very informative and technical. Just what the doctor ordered. 10/10
Good high-level explanation, I encourage people interested to read the papers published and do some research about branch prediction. For starters, Tomasulo's algorithm was one of the first OOO execution designs that many processors are still based off of. It's old, so it's easier to comprehend then today's massively complicated schemes, but will still give you a taste of what happens at the h/w level.
Yeah just let me crack open my iMac and replace the CPU that should be pretty easy
I like how; while under development, the patch that was applied by Linux devs was given the name "Forcefully Unmap Complete Kernel With Interrupt Trampolines", it was changed for the actual release of the patch because of the same reason as why I like the name... spell out the first letter of each word xD
Excellent video. Very informative and interesting. I just knew Computerphile would cover this.
too lazy to do my own research on this topic, since I know computerphile will do a better job. Finally it is here, and im not disappointed
I seen this coming from the moment I began experimenting with parallel programming techniques. Having developed a lot of creative uses of Semaphores to get around the pitfalls of out of order execution, I will be incredibly happy when we start to see processors that don't pretend to know better than the programmer what order their instructions should be executed. I should never have to suspect memory barriers I drop into my code aren't actually doing anything but you would be surprised just how often modern processors completely ignore their presence.
The title needs to be better. Before I knew what spectre & meltdown were I had no desire to watch this video. Then I watched The WAN Show and now I want to.
Ubeogesh would you prefer something clickbaity and irrelevant...?
And to make it clear, the Meltdown bug, which has the highest likelihood of speed degradation, does not effect AMD CPUs.
Wow, very fast content reaction to current "Computerphile" topics. Great!
By the way: does CERT list hardware which is considered "secure" in terms of Spectre and Meltdown?
Love the shirt
He was my lecturer last year and for a lecture on the ALOHA computer network on *1 slide* he wore a hawaiian shirt for that reason alone.
I enjoy videos where 200 nanoseconds is 'a reasonably long time'
So, the way to solve this would be to throw out cache lines that were read in by speculatively executed code, right? Does the branch predictor set any flags that could be used as a trigger for an interrupt handling such a thing?
So long as you are not using a real-time operating system the slight delay should be virtually undetectable.
If the CPU had to be redesigned, the branch predictor may simply need his own dedicated cache lines for backup storage.
Raspberry Pi's blog did an awesome job explaining this. (Mainly because they actually showed (pseudo-)code)
Very good explanation, thanks guys!
Expected a deeper explanation, considering this is computerphile
TH-cam thought I was going to watch this video, but I looked at how long it was and decided not to. Instead, I watched a Numberphile video really carefully, and now I know everything that's said in this video. I don't think that's supposed to happen.
4:48 Dr Bagley is creating an 'off by one' error. In most languages that array would contain 17 items, not 16. Thanks for the buffer overflow, dr Heartbleed.
No it wouldn't. The number between brackets is the amount of elements. He starts at 1 and ends at 16, which is a total of 16.
A big thumbs up! BTW, could you please add subtitle functionality in the videos?
Thanks for the explanation.
Thank you!
Steve Bagley Thumbs up for mentioning the BSDs. Their developers haven't been a part of the embargoed information, even though they run a pretty significant part of the Internet's backends...
Is the out of order execution order determined by hardware? It sounds like a software kind of thing to calculate that. And if that is solved then the security checks will be done in time.
Super fast :) Most media is not ready yet to explain it well.
I followed everything up to getting the data out of the cache... How do you get the data once it is in the cache? It could be anywhere in the cache especially once you go far beyond the array end. Even if you knew the exact cache line, how would you retrieve it in user mode anyway?
Could older CPU technology be (more) advantageous when dealing with this "threat", or is it a generation gap exploit?
One question, though: how does the malware/hacker know what it/he/she's looking at? -ok, things can be pulled out of memory at the CPU level, but as far as I understand it, it's another three levels (kernel, API and application) before that data is human readable and in context. Good luck figuring out I'm watching a Heartstone commercial on TH-cam. Also... execution speed seems quite slow, won't locations be overwritten with something else before the program has run it's cycle, further complicating matters?
Anyone have a link to the code Steve is walking through?
I've been reading very mixed opinions on the likely effect on Intel CPU performance. I'd love to hear a detailed and unbiased explanation of this. Also, does this mean consumers should avoid buying new computers until the next generation of redesigned CPUs?
It has been over three years now, do you know which, if any CPUs have "fixed" this problem?
Great explanation many thanks
Question: Since most computers from atleast the early 90s - present have this flaw with the new security issue, would it be possible (if having an old development unit for a videogame system or something (say N64) or a dev cartridge) would it be theoretically possible with the right tools (and the Meltdown/Spectre flaws) to obtain source code/ documentation on videogames in which the source code was thought to be locked down under the aformentioned cartridge/cpu ?
Is there a way to disable the cache entirely in modern CPUs? Perhaps from the BIOS? That might be a temporary fix, despite the massive slowdown it may cause
Cool, this is from the university of Nottingham, same place that makes those awesome Periodic Videos about chemistry and elements!
+Auriam certainly is! >Sean
Bring Dr Pound. He explains things in a much better manner. Easy to follow along.
I find the term "favorite operating system of the month" so funny. 3:11
The science behind the exploits is very interesting.
Reminds me of that Computerphile video about the exploit of cache memory byway of specific SQL queries.
so how would this impact major security like fb1 and C1A.....??
Love the juxtaposition of Hawaiian shirt and grey sky. Very informative as always.
Very timely. Good job. :)
Who is going to make the replacement CPU, where do I request one and who will pay for the cost of the replacement?
Thank you! Have been wondering how this actually worked, media have been pretty universally poor in how they're covering this (as usual).
Then again it's pretty difficult to explain to the layman apparently, I'm not far from that but I think I just about get it.
Does the 'patch' simply hinder speculative evaluation?
I understand how you can read the prefetched piece of memory that exceeds the array size check, but a prefetcher doesn't prefetch the entire memory. How is it that you can read everything instead of just the first bits after the end of your own program space?
Great video!
Would you be able to get information from another virtual server if they both lived on the same host?
Do you mean the hardware architecture of the MPU? or the microcode? ...or both?
Is the party over for crypto with Meltdown and Spectre around? I am feeling bummed-out because I deeply wanted crypto to be my new career. I do have a ledger, but wanted to speculate on ICO's and low-cap crypto's also. I was planning on using MyEtherWallet for erc-20 tokens. Thoughts?
Thanks for this interresting and easy-to-understand explanation of the exploit. However, one thing remains unclear to me: This is a bug in the hardware, so how can it be patched in the OS?
What VSCode skin is that? Looks really nice.
I cant think of anything I wouldnt rather do instead of computer security. What a nightmare ... constantly a new battle you will inevitably lose
Is this severe enough for sandboxed instances to be able to access resources it shouldn't? To me it seems to be possible for the vulnerability to grant access to code outside of that sandboxed state. If so, this would be a very bad issue indeed.
I was hoping you would make a video on this!
There has been talk about this for some time (for years), so I'm not sure why this is suddenly seen as a huge problem now. Though I gather nobody knew exactly how to exploit this vulnerability before, and that someone finally decided to make a proof-of-concept.
kebman Because it IS a huge problem. The ultimate consequences of these exploits are absolutely massive.
the one thing i dont really get is, why it is an hardware issue. I mean how can speculative branch evaluation, or rather the logic behind it be implemented in hardware. Or is it?
So does speculative evaluation just have to go away? Is this a fundamental problem with the idea of speculative evaluation or a specific implementation of it? Sucks if a whole idea for fast computing has to go away. :-(
Also, where is the stock-pile they pull from w/ the old printer paper, haha?! Love it.
Could we get the source code for that program that exploits itself? I’m really interested to see how it works myself.
Could the CPU architecture be programmed so that coders have more control over what is loaded into cache? I mean indexing in cache is useful but could we have say a keyword in languages that says "this data shouldn't be cached". Maybe somewhere in memory would be reserved specifically for types of important data that should never be cached? I know it would cause performance issues if this was frequently used but is this a sort of viable solution (I realise regular RAM access is waaay slower than even L3 cache)
Surely it shouldn't execute a copy from array1 to array2 unless the instruction was from the same program?
@2:30 - In what universe is "running slightly slower" a "significant impact"?
Wow. There's something like 20 years worth of processors which are vulnerable to this family of exploits. Wasn't the Pentium Pro Intel's first out-of-order processor? That came out in the mid-to-late 1990s, so we're in pretty hot water with this lot.
Cool, that's actually pretty easy to understand.