AN' DERE AIN'T NO SUCH FING AS ENUFF DAKKA, YA GROT! Enuff'z more than ya got an' less than too much an' there ain't no such fing as too much dakka. Say dere is, and me Squiggoff'z eatin' tonight!
We are born of the blood. Made men by the blood. Undone by the blood. Our eyes are yet to open. FEAR THE OLD BLOOD.
Reading these indicates that the fundamental issue stems from how computing has developed in the last few years. As the Spectre paper concludes the drive to maximise performance.
Both papers make clear that as all manufacturers / developers have gone in the same general direction this a cross-hardware, cross-operating system issue. The fact that something they did worked on one combo and not another, in their opinion, doesn't suggest a given combo is "immune" simply that they hadn't got the "attack" right.
What is comforting is that this stuff is pursued by e.g. the EU and fully supported by Intel/Qualcomm/AMD/ARM/MS/Google etc.
And its why people should keep their software up-to-date! (Yes, yes its the Martian conspiracy.)
There are plenty of gradations between vulnerable and immune. "I believe it's possible" is a long way from "I've demonstrated how to do it". And a proof of concept is itself a long way from cyber-criminals being able to use it to steal from you. You can't make computers 100% immune to all possible exploits, but if one system is considerably harder to attack than another, that's a big deal.
Agree. And it would be a big deal. However:
If they spent x months (say) getting something to work on one but couldn't get that key to work on a different combo after a week (say) of tweaks that doesn't mean that they couldn't develop a key from scratch in x months (say).
Clearly there was a given level of funding coupled with the impetus to make the information available to interested parties especially as they had proof of concept across all platforms. Also interesting that they were doing this stuff on Haswells - suggesting the initial work pre-dates the latest generation cpus.
So I totally agree with what you say but its not a conclusion they jump to. The door is there is what they are essentially saying.
Wasn't Linus a contributor on Transmeta? Not that Transmeta really went anywhere, and maybe that's your point.
Linus is worthy of some admiration, in the same vein as Carmack, Romero, Wozniak, Gates, Hopper, Englebart, Bush, Kay, and other legends in the computer industry.
He's still entitled to his opinion on things, but yeah, that doesn't necessarily mean his opinion on things (outside of Linux Kernals specifically) really carries any more weight than any other armchair quarterback.
Just about every Intel processor that has released since Bloomfield in 2008 is affected. Some of the early Atom CPUs might not be, as speculative execution doesn't make sense on an architecture that doesn't support out of order execution.
If you want to go all conspiracy theorist like Wizardry, then here's something that should raise eyebrows:
Apparently Intel's CEO sold as much of the company stock as he was contractually allowed to after learning of the flaw. It's common for CEOs to set plans to sell stock far in advance so as to avoid allegations of insider trading because something negative happens shortly before they were going to sell the stock anyway. But he only set his plan to sell the stock about a month before he actually sold it, and well after Google had informed Intel of the problem.
Well, there you have it. Desktop users have little to worry about in terms of performance loss, particularly gamers. We've yet to test older CPUs, but given the type of workloads we’re seeing impacted by the patch, I don’t think there’s going to be an issue with any desktop hardware, but we’ll certainly report back if there is.
The reduction in 4K read performance for high speed NVMe drives is a concern and while this shouldn’t impact any games, any application that is sensitive to this might show a reduction in performance. Of course the brief list of applications I tested showed no real reduction in performance period.
The issue nonetheless remains and is one that has a far bigger potential in affecting servers. It's a serious concern for data centers both on the side of performance and more importantly, security. That's not our area of expertise or interest, so we'll leave that testing to those better equipped to tackle it.
Passwords would not be stored long-term in kernel memory. If done properly, passwords shouldn't be stored long-term anywhere. Rather, you hash a password and store the hash. The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.
*snip*
Thank you, the whole response filled in some blanks for me.
Then does this mean a keylogger would be better for the purpose of reading information than this exploit? I guess getting someone to visit your website would be easier than getting them to install your keylogger though.
Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue. Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen? Or is it just that the feature itself is inherently risky?
Passwords would not be stored long-term in kernel memory. If done properly, passwords shouldn't be stored long-term anywhere. Rather, you hash a password and store the hash. The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.
*snip*
Thank you, the whole response filled in some blanks for me.
Then does this mean a keylogger would be better for the purpose of reading information than this exploit? I guess getting someone to visit your website would be easier than getting them to install your keylogger though.
Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue. Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen? Or is it just that the feature itself is inherently risky?
Well what Quiz says is true and all,
But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.
This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.
It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.
But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.
This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.
It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.
One would hope that information would be encrypted. However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).
I am more worried about the government systems. Honestly, our information is not safe, now especially when this vulnerability.
Passwords would not be stored long-term in kernel memory. If done properly, passwords shouldn't be stored long-term anywhere. Rather, you hash a password and store the hash. The hash itself could be stored in the clear, but given a good password and a good hash function, recovering the password from the hash of it is impractical.
*snip*
Thank you, the whole response filled in some blanks for me.
Then does this mean a keylogger would be better for the purpose of reading information than this exploit? I guess getting someone to visit your website would be easier than getting them to install your keylogger though.
Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue. Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen? Or is it just that the feature itself is inherently risky?
If you're trying to steal someone's password, then yes, a keylogger is a more effective way to do it than a meltdown attack. Of course, you can't just kindly ask someone to install a keylogger so that you can steal his password and expect much in the way of success. It takes using some sort of security flaw (if one counts idiot users as a security flaw) to get the keylogger installed in the first place.
As Ridelynn said, stealing a user's password is hardly the worst of it. It's far more of a problem for cloud servers with a ton of virtual machines than it is for consumers.
But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.
This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.
It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.
One would hope that information would be encrypted. However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).
I am more worried about the government systems. Honestly, our information is not safe, now especially when this vulnerability.
Even if the information is encrypted at rest, it has to be decrypted for someone to do anything useful with it. The problem with meltdown is that it could let one user see another user's ordinarily encrypted information while its decrypted in memory.
If you want crazy conspiracy theory, one wonders how long No Such Agency and the Company have known about this?... Not to mention what ever else they are keeping to themselves.
But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.
This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.
It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.
One would hope that information would be encrypted. However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).
I am more worried about the government systems. Honestly, our information is not safe, now especially when this vulnerability.
Yeah that's the scary part about these vulnerabilities. It doesn't matter if your information is encrypted if the keys get stolen.
Ryzen not affected. Does this make Ryzen more desirable do you think?
The question isn't whether it makes Ryzen relatively more appealing, but how much. It could be anywhere from a rounding error to Ryzen suddenly being the CPU with the best per-core performance.
Is Ryzen really not affected? My local newspaper said it affected ARM chips and AMD chips as well but didn't specify the models.
Yeah, I havn't bothered to read up on it myself, havn't gotten much sparetime lately and you usually know this kind of stuff...
Ryzen not affected. Does this make Ryzen more desirable do you think?
The question isn't whether it makes Ryzen relatively more appealing, but how much. It could be anywhere from a rounding error to Ryzen suddenly being the CPU with the best per-core performance.
Is Ryzen really not affected? My local newspaper said it affected ARM chips and AMD chips as well but didn't specify the models.
Yeah, I havn't bothered to read up on it myself, havn't gotten much sparetime lately and you usually know this kind of stuff...
There are multiple attacks, and some people (that is, Intel) wants to run them all together to confuse people.
Meltdown is a clearer, easier to implement class of attacks that nearly all Intel CPUs of the last decade are vulnerable to, but recent AMD CPUs (including Ryzen, FX series, recent APUs, etc.) are categorically immune to. Meltdown can be patched away in software, but doing so brings a performance hit, as you have to play games to force the CPU to clear some caches when switching from one user to another or between a user and the kernel. For consumer use, the performance hit will tend to be minimal (e.g., 1%), but for servers running a lot of virtual machines that need to share time on a CPU without mixing their data together, the performance hit could be huge. That's the common scenario that led people to cite a 30% performance hit.
Spectre is a much more nebulous and harder to implement class of attacks. Thus far, the only public, successful implementation of Spectre on an AMD CPU required changing some kernel settings to not be the default. There have been successful implementations of Spectre on Intel and ARM CPUs without having to change other system settings, but running the same implementation on an AMD CPU failed. People vaguely believe that Spectre can be done on AMD CPUs, but that they just haven't gotten the details quite right yet.
Spectre is not so much a single attack as a new class of attacks. You can apply a software patch to fix any particular attack in the class that shows up, and with a negligible performance hit. But you can't make a patch that will categorically fix Spectre entirely. The only 100% fix for it would be to drop speculative execution entirely, which would require physically replacing the CPUs with other, much slower CPUs.
Spectre being so hard to implement and so hardware-dependent makes me think that it might never really amount to anything. Certainly, they should patch to fix any particular example of it that researchers can come up with. And I'm not saying that Spectre should be ignored; it might end up being a huge problem. But it wouldn't be surprising if a decade from now, there hasn't been a single significant malware or hacking incident that relied on a Spectre attack.
In terms of the relative desirability of various hardware, I don't think that Spectre really changes anything. Meltdown is only marginally relevant to consumer use, and the net advantage to AMD over Intel is basically a rounding error, so it's not a very strong reason to prefer Ryzen over Coffee Lake unless you're doing something very unusual.
Servers are where Meltdown is a huge deal, and it is a strong reason to favor Epyc over Xeon if you're running a ton of virtual machines. You probably won't see an official, public announcement of this happening, but it wouldn't be surprising if Amazon or Google or some other company with a huge cloud presence places a huge order for Epyc CPUs that would have been Xeon if not for Meltdown.
For any future server CPUs that aren't too far along into the design to change it, Intel will presumably fix Meltdown in hardware so that it doesn't need the patch to slow it down. For such CPUs to show up at retail could easily be 2-3 years away, however, which leaves a lot of time for AMD to sell Epyc CPUs.
There is an enormous caveat that I don't entirely understand it, so I might well be getting some detail(s) wrong, but I think that Meltdown goes something like this:
A program does a system call to get some kernel memory loaded into a CPU's L1 cache, and then the kernel finishes what it was asked to do and returns control to the user program, while still having some kernel memory cached in L1.
The program then has a for loop that asks the program to compute B[A[x]] repeatedly and do something with it. It ensures that all of the calls are legitimate and within the bounds of the array except for the last one. The earlier calls in the for loop are to get speculative execution to guess that the last one will also be legitimate and speculatively execute it until it realizes that it has to abort because it's invalid.
The last call doing B[A[x]] with x outside the bounds of A tries to access something in kernel memory, then do a table lookup using the value as an address. Because this speculatively executes, the CPU loads something into L1 cache, and has to evict something else from L1 cache to make room. Which data it clears out of cache depends on the value of A[x], that is, the data in kernel memory. Thus, even after speculative execution terminates and says that you're not allowed to see A[x], nor B[A[x]], you can still check to see which values are still in L1 cache by trying to access them and timing to see how long it takes. If it's still in L1 cache, it will be faster than having to go to L2 cache.
This can't get you the full 64 bits of A[x] in a single go, but you have time to do a few very fast operations and get some of the bits each time. After enough iterations, you have all of A[x]--an 8 byte value from kernel memory. Then you can repeat to try to get another 8 byte value from kernel memory. Apparently they've got an attack that can read kernel memory at a rate of about 2 KB/sec.
So why are AMD CPUs immune to this? If an AMD CPU sees that you have some kernel memory in L1 cache, it decides that user code is not allowed to do speculative execution. Thus, when you try to compute B[A[x]], it checks to see if A[x] is inside user memory before computing B[A[x]]. When it isn't, it never computes B[A[x]], so it never evicts something from L1 cache to make room for B[A[x]] and the attack completely fails. Researchers were able to get a similar attack to have one program read the "wrong" memory from the same program on an AMD CPU, but that's not a security problem in itself, as a program is allowed to see all if its own memory.
AMD CPUs do take some performance hit for refusing to do speculative execution shortly after returning from a system call. That performance hit is far milder than the solution to fix the security hole on an Intel CPU, however. On an Intel CPU, the patch is to forcibly clear the entire contents of the L1 cache whenever a kernel returns from a system call so that there is no kernel memory left in L1 cache. They can do that by loading a bunch of junk to get it cached in L1 until all of the "real" kernel memory that was cached in L1 has been forced out to make room. You could still run the attack, but instead of it recovering the memory that the kernel is actually using, it would only recover some junk that the kernel intentionally filled L1 cache with before returning from a system call.
So why aren't AMD CPUs also immune to Spectre? They don't want to stop speculative execution whenever L1 cache merely has data from different threads or different processes from the same user. That situation is very, very common, and would cause a huge performance hit if speculative execution were disabled. Spectre won't allow a program to read kernel memory, but it can allow a program to read another program's memory that it shouldn't have access to.
Spectre is much harder to get anything useful out of than Meltdown, however. There are vastly more programs than OS kernels in the world, and it's much harder to know which version of which program with its memory arranged in which way that you're looking at. The only program data that will be in L1 cache is that which is actively being used--and likely in the process of being changed, anyway. You also don't have a nice way to get some other program to load the data you want to see into L1 cache, whereas you can easily get kernel memory loaded by doing a system call in the middle of your program to ask the kernel to do something.
"We all do the best we can based on life experience, point of view, and our ability to believe in ourselves." - Naropa "We don't see things as they are, we see them as we are." SR Covey
One of the posters at Epic had a really good explanation - he even talks about this versus something like a keylogger. In essence, you can think of these attacks as keyloggers for your CPU caches. The "patch" involves extra encryption steps for data that is intended to be encrypted, so that the CPU is processing encrypted data, and that adds a lot of overhead.
You probably won't see a big impact on your gaming computer, unless you run something like an encrypted SSH tunnel or VPN service full time. Most typical home/gaming computers don't deal with a lot of encrypted data streams, apart from the occasional password hash or https header whenever you log into something.
Servers, on the other hand... and Epic is saying they are seeing a lot of issues on their cloud servers for Fortnite right now.
My entire work world lives on encrypted data, virtual machines, and various VPN tunnels. I use VMs because I run VPNs from my desktop and RDP to remote hosts. That way I can do my remote work securely while still having access to the internet on my desktop.
I also run my entire data drive through TrueCrypt at the partition level. I don't use it for my OS drive which is physically separate. I'm keeping my eyes out for a big performance hit.
How I think this might play out pragmatically is that we could feel a cumulative performance hit. I don't expect my VM to suddenly become slower. I expect the VM, and VPN, and the entire virtualized host network to all contribute small pieces to performance degradation. I'm not entirely sure we'll even feel that in real time interaction. I think we'll see that in longer processing times that add up to larger loss of productivity.
I expect to see this in my ETL (extract, transform, load) jobs between databases or in file conversions. For example, say I have to move 100k patients between systems with 500GB of discrete data and it used to take me 20 hours. If that now takes me 26 hours of processing time, that can balloon into a couple more days of people time which adds a huge amount of cost or loss to my productivity and our revenue.
It's even worse I fear with file conversions. I do a lot of those between systems. Medical people scan a lot and create a lot of documents and they often want them converted to formats for a new system or packaged into a single PDF. Converting 10 million files and moving them to a new location can take weeks depending on hardware. Even a 5% across the board increase is going to be incredibly painful. I'm hoping in this situation that I/O is still the main bottleneck.
I'm also curious how this will affect performance for interpreted languages. Java, .NET, and Python all use an interpreter which is essentially a virtualization layer that interprets byte code to binary. We use those heavily and most of our third party tools are written in Java and .NET.
Like Quizz said this is actually a set of issues and there is a lot to chew on and unpackage. I'm not worried about security or my personal information on Amazon so much as how this will affect the tech landscape productivity.
It's possible that you won't be particularly affected by the fix. My understanding is that it doesn't make using a VM slower on its own. What hurts is switching between VMs. If you're using a VM for security reasons, but you're the only VM on the server, then you don't have a problem of switching between VMs, so you won't have a big performance hit. If there are 10 VMs on a physical server but yours is the only one doing much, then it won't have to switch to another VM to let it have some CPU time very much, so again, the performance hit won't be large. If yours is one of several VMs actively doing a lot of work on the same physical server and competing for CPU time, then the patch will basically impose a much larger context switching penalty to switch between them, and that's how it gets really bad.
Encrypting and decrypting data is just software, so the patch shouldn't affect the speed of that. Nor should it affect the performance of changing file formats. A VPN might be a problem depending on how often it is forced to do system calls, but I suspect that it won't be a big deal.
If you're doing database work where the database is large enough that you can't keep it in memory and it's a ton of very small file I/O, then that could be a problem. Having a ton of very short system calls so that you have to constantly switch between user memory and kernel memory will impose a considerable hit every time you switch.
My entire work world lives on encrypted data, virtual machines, and various VPN tunnels. I use VMs because I run VPNs from my desktop and RDP to remote hosts. That way I can do my remote work securely while still having access to the internet on my desktop.
I also run my entire data drive through TrueCrypt at the partition level. I don't use it for my OS drive which is physically separate. I'm keeping my eyes out for a big performance hit.
How I think this might play out pragmatically is that we could feel a cumulative performance hit. I don't expect my VM to suddenly become slower. I expect the VM, and VPN, and the entire virtualized host network to all contribute small pieces to performance degradation. I'm not entirely sure we'll even feel that in real time interaction. I think we'll see that in longer processing times that add up to larger loss of productivity.
I expect to see this in my ETL (extract, transform, load) jobs between databases or in file conversions. For example, say I have to move 100k patients between systems with 500GB of discrete data and it used to take me 20 hours. If that now takes me 26 hours of processing time, that can balloon into a couple more days of people time which adds a huge amount of cost or loss to my productivity and our revenue.
It's even worse I fear with file conversions. I do a lot of those between systems. Medical people scan a lot and create a lot of documents and they often want them converted to formats for a new system or packaged into a single PDF. Converting 10 million files and moving them to a new location can take weeks depending on hardware. Even a 5% across the board increase is going to be incredibly painful. I'm hoping in this situation that I/O is still the main bottleneck.
I'm also curious how this will affect performance for interpreted languages. Java, .NET, and Python all use an interpreter which is essentially a virtualization layer that interprets byte code to binary. We use those heavily and most of our third party tools are written in Java and .NET.
Like Quizz said this is actually a set of issues and there is a lot to chew on and unpackage. I'm not worried about security or my personal information on Amazon so much as how this will affect the tech landscape productivity.
Well a friends company has taken their VM machines and VPN's off the net entirely. It does take data longer to get into the system because of this, but with files of millions of users they just cannot take any kind of a performance hit.
Microsoft released info about how much the security fixes will decrease performance:
Windows 10 is slowed down less than Windows 8 and Windows 7 Intels' Skylake processors and later (6000 series and later) is slowed down less than earlier Intel processors.
If you're using Windows 10 and modern processor the slowdown should be only single digit and most users won't notice anything. If you're unlucky and are using older OS + older processor the slowdown will be so large that most users will notice decreased performance.
There are two updates required for the security fixes: One for the OS, one for processor microcode. Most of the current slowdown benchmarks are done with only one of those updates, and don't show the full truth of how much the computer will be slowed down.
Intel has released an update addressing the patches the company has issued to resolve recently-revealed, massive CPU security flaws, and the performance hits (and other quirks) users are experiencing in the wake of the updates. The "Meltdown" and "Spectre" errors opened the door to exploits that allow an attacker to swipe data from a PC running millions of CPUs made since the mid-nineties.
The scope of the flaw was monumental, though the affair was compounded by security updates that have impacted performance and system stability.
Not only are users who applied these updates now facing notable performance degradation of their CPUs, some customers are seeing constant reboots in the wake of Intel's solution to the problem, something Intel addressed in its blog post.
"We have received reports from a few customers of higher system reboots after applying firmware updates," Intel states. "Specifically, these systems are running Intel Broadwell and Haswell CPUs for both client and data center. We are working quickly with these customers to understand, diagnose and address this reboot issue."
Intel's post came on the heels of a Wall Street Journal story claiming that Intel is teling some customers to delay applying the update to avoid system stability problems. That report cited an internal Intel document disclosing that the company identified three issues in microcode updates released over the past week intended to address the vulnerabilities. The warnings were shared with computer makers and large cloud providers, but not consumers or smaller companies.
Another Intel update clarifies just what kind of a performance hit impacted users are seeing on their systems after applying updates.
According to Intel, computers equipped with 8th generation (Kaby Lake, Coffee Lake) chips and sold-state-drives (SSDs) will see the least slowdown from the Spectrum/Meltdown update at less than 6%. Devices using the 7th Gen Kaby Lake-H mobile processors will be around 7% slower, while the performance impact on systems with the 6th Gen Skylake-S platform is estimated to be around 8%. Needless to say, enterprise users and hobbyists alike are immensely frustrated by having to choose between system security and system stability and performance, and that Intel isn't being fully forthright with some customers.
"As we collect more information across the broad range of usages and Intel platforms, we will make it available," Intel says of the slowdowns and rebooting issues. "Within the next week, we intend to offer a representative set of data for mobile and desktop platforms that were launched within the past five years. For those Intel customers who are worried about performance impacts, you should know that we will work on creative solutions with our industry partners to reduce those performance impacts wherever possible."
Brenics ~ Just to point out I do believe Chris Roberts is going down as the man who cheated backers and took down crowdfunding for gaming.
Comments
AN' DERE AIN'T NO SUCH FING AS ENUFF DAKKA, YA GROT! Enuff'z more than ya got an' less than too much an' there ain't no such fing as too much dakka. Say dere is, and me Squiggoff'z eatin' tonight!
We are born of the blood. Made men by the blood. Undone by the blood. Our eyes are yet to open. FEAR THE OLD BLOOD.
#IStandWithVic
If they spent x months (say) getting something to work on one but couldn't get that key to work on a different combo after a week (say) of tweaks that doesn't mean that they couldn't develop a key from scratch in x months (say).
Clearly there was a given level of funding coupled with the impetus to make the information available to interested parties especially as they had proof of concept across all platforms. Also interesting that they were doing this stuff on Haswells - suggesting the initial work pre-dates the latest generation cpus.
So I totally agree with what you say but its not a conclusion they jump to. The door is there is what they are essentially saying.
https://www.amd.com/en/corporate/speculative-execution
Linus Torvalds is not impressed with Intel's PR statement:
https://lkml.org/lkml/2018/1/3/797
Linus is worthy of some admiration, in the same vein as Carmack, Romero, Wozniak, Gates, Hopper, Englebart, Bush, Kay, and other legends in the computer industry.
He's still entitled to his opinion on things, but yeah, that doesn't necessarily mean his opinion on things (outside of Linux Kernals specifically) really carries any more weight than any other armchair quarterback.
Just about every Intel processor that has released since Bloomfield in 2008 is affected. Some of the early Atom CPUs might not be, as speculative execution doesn't make sense on an architecture that doesn't support out of order execution.
If you want to go all conspiracy theorist like Wizardry, then here's something that should raise eyebrows:
http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1
Apparently Intel's CEO sold as much of the company stock as he was contractually allowed to after learning of the flaw. It's common for CEOs to set plans to sell stock far in advance so as to avoid allegations of insider trading because something negative happens shortly before they were going to sell the stock anyway. But he only set his plan to sell the stock about a month before he actually sold it, and well after Google had informed Intel of the problem.
https://www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows/
Conclusion, so far
Well, there you have it. Desktop users have little to worry about in terms of performance loss, particularly gamers. We've yet to test older CPUs, but given the type of workloads we’re seeing impacted by the patch, I don’t think there’s going to be an issue with any desktop hardware, but we’ll certainly report back if there is.
The reduction in 4K read performance for high speed NVMe drives is a concern and while this shouldn’t impact any games, any application that is sensitive to this might show a reduction in performance. Of course the brief list of applications I tested showed no real reduction in performance period.
The issue nonetheless remains and is one that has a far bigger potential in affecting servers. It's a serious concern for data centers both on the side of performance and more importantly, security. That's not our area of expertise or interest, so we'll leave that testing to those better equipped to tackle it.
Thank you, the whole response filled in some blanks for me.
Then does this mean a keylogger would be better for the purpose of reading information than this exploit? I guess getting someone to visit your website would be easier than getting them to install your keylogger though.
Additionally, this was deemed a hardware issue, but my laymen understanding wants to say this seems more like a software issue. Is it accurate to say that the software implementation of this "Speculative Execution" feature is allowing the exploit to happen? Or is it just that the feature itself is inherently risky?
But the danger of these particular flaws is, someplace, something has to calculate the hash against a key, and see if it matches.
This flaw may not get you a plaintext password, but it ~can~ expose hashes and keys, which is all you need to get to a plaintext password.
It's a huge deal in the server realm, particularly cloud servers. The people who are looking to leverage it won't necessarily be looking for your password on your PC. But imagine if they could get on an Amazon AWS server, or Microsoft Azure server, or a Google data center - all the hundreds/thousands/millions of credentials from one infection.
One would hope that information would be encrypted. However, I worked at a place where we knew that was a huge vulnerability, but the cost of going back and retrofitting encryption was enormous (I was responsible for getting funding for it).
I am more worried about the government systems. Honestly, our information is not safe, now especially when this vulnerability.
As Ridelynn said, stealing a user's password is hardly the worst of it. It's far more of a problem for cloud servers with a ton of virtual machines than it is for consumers.
Yeah, I havn't bothered to read up on it myself, havn't gotten much sparetime lately and you usually know this kind of stuff...
Meltdown is a clearer, easier to implement class of attacks that nearly all Intel CPUs of the last decade are vulnerable to, but recent AMD CPUs (including Ryzen, FX series, recent APUs, etc.) are categorically immune to. Meltdown can be patched away in software, but doing so brings a performance hit, as you have to play games to force the CPU to clear some caches when switching from one user to another or between a user and the kernel. For consumer use, the performance hit will tend to be minimal (e.g., 1%), but for servers running a lot of virtual machines that need to share time on a CPU without mixing their data together, the performance hit could be huge. That's the common scenario that led people to cite a 30% performance hit.
Spectre is a much more nebulous and harder to implement class of attacks. Thus far, the only public, successful implementation of Spectre on an AMD CPU required changing some kernel settings to not be the default. There have been successful implementations of Spectre on Intel and ARM CPUs without having to change other system settings, but running the same implementation on an AMD CPU failed. People vaguely believe that Spectre can be done on AMD CPUs, but that they just haven't gotten the details quite right yet.
Spectre is not so much a single attack as a new class of attacks. You can apply a software patch to fix any particular attack in the class that shows up, and with a negligible performance hit. But you can't make a patch that will categorically fix Spectre entirely. The only 100% fix for it would be to drop speculative execution entirely, which would require physically replacing the CPUs with other, much slower CPUs.
Spectre being so hard to implement and so hardware-dependent makes me think that it might never really amount to anything. Certainly, they should patch to fix any particular example of it that researchers can come up with. And I'm not saying that Spectre should be ignored; it might end up being a huge problem. But it wouldn't be surprising if a decade from now, there hasn't been a single significant malware or hacking incident that relied on a Spectre attack.
In terms of the relative desirability of various hardware, I don't think that Spectre really changes anything. Meltdown is only marginally relevant to consumer use, and the net advantage to AMD over Intel is basically a rounding error, so it's not a very strong reason to prefer Ryzen over Coffee Lake unless you're doing something very unusual.
Servers are where Meltdown is a huge deal, and it is a strong reason to favor Epyc over Xeon if you're running a ton of virtual machines. You probably won't see an official, public announcement of this happening, but it wouldn't be surprising if Amazon or Google or some other company with a huge cloud presence places a huge order for Epyc CPUs that would have been Xeon if not for Meltdown.
For any future server CPUs that aren't too far along into the design to change it, Intel will presumably fix Meltdown in hardware so that it doesn't need the patch to slow it down. For such CPUs to show up at retail could easily be 2-3 years away, however, which leaves a lot of time for AMD to sell Epyc CPUs.
A program does a system call to get some kernel memory loaded into a CPU's L1 cache, and then the kernel finishes what it was asked to do and returns control to the user program, while still having some kernel memory cached in L1.
The program then has a for loop that asks the program to compute B[A[x]] repeatedly and do something with it. It ensures that all of the calls are legitimate and within the bounds of the array except for the last one. The earlier calls in the for loop are to get speculative execution to guess that the last one will also be legitimate and speculatively execute it until it realizes that it has to abort because it's invalid.
The last call doing B[A[x]] with x outside the bounds of A tries to access something in kernel memory, then do a table lookup using the value as an address. Because this speculatively executes, the CPU loads something into L1 cache, and has to evict something else from L1 cache to make room. Which data it clears out of cache depends on the value of A[x], that is, the data in kernel memory. Thus, even after speculative execution terminates and says that you're not allowed to see A[x], nor B[A[x]], you can still check to see which values are still in L1 cache by trying to access them and timing to see how long it takes. If it's still in L1 cache, it will be faster than having to go to L2 cache.
This can't get you the full 64 bits of A[x] in a single go, but you have time to do a few very fast operations and get some of the bits each time. After enough iterations, you have all of A[x]--an 8 byte value from kernel memory. Then you can repeat to try to get another 8 byte value from kernel memory. Apparently they've got an attack that can read kernel memory at a rate of about 2 KB/sec.
So why are AMD CPUs immune to this? If an AMD CPU sees that you have some kernel memory in L1 cache, it decides that user code is not allowed to do speculative execution. Thus, when you try to compute B[A[x]], it checks to see if A[x] is inside user memory before computing B[A[x]]. When it isn't, it never computes B[A[x]], so it never evicts something from L1 cache to make room for B[A[x]] and the attack completely fails. Researchers were able to get a similar attack to have one program read the "wrong" memory from the same program on an AMD CPU, but that's not a security problem in itself, as a program is allowed to see all if its own memory.
AMD CPUs do take some performance hit for refusing to do speculative execution shortly after returning from a system call. That performance hit is far milder than the solution to fix the security hole on an Intel CPU, however. On an Intel CPU, the patch is to forcibly clear the entire contents of the L1 cache whenever a kernel returns from a system call so that there is no kernel memory left in L1 cache. They can do that by loading a bunch of junk to get it cached in L1 until all of the "real" kernel memory that was cached in L1 has been forced out to make room. You could still run the attack, but instead of it recovering the memory that the kernel is actually using, it would only recover some junk that the kernel intentionally filled L1 cache with before returning from a system call.
So why aren't AMD CPUs also immune to Spectre? They don't want to stop speculative execution whenever L1 cache merely has data from different threads or different processes from the same user. That situation is very, very common, and would cause a huge performance hit if speculative execution were disabled. Spectre won't allow a program to read kernel memory, but it can allow a program to read another program's memory that it shouldn't have access to.
Spectre is much harder to get anything useful out of than Meltdown, however. There are vastly more programs than OS kernels in the world, and it's much harder to know which version of which program with its memory arranged in which way that you're looking at. The only program data that will be in L1 cache is that which is actively being used--and likely in the process of being changed, anyway. You also don't have a nice way to get some other program to load the data you want to see into L1 cache, whereas you can easily get kernel memory loaded by doing a system call in the middle of your program to ask the kernel to do something.
How to Check and Update Windows Systems for the Meltdown and Spectre CPU Flaws
https://www.bleepingcomputer.com/news/microsoft/how-to-check-and-update-windows-systems-for-the-meltdown-and-spectre-cpu-flaws/"We all do the best we can based on life experience, point of view, and our ability to believe in ourselves." - Naropa "We don't see things as they are, we see them as we are." SR Covey
You probably won't see a big impact on your gaming computer, unless you run something like an encrypted SSH tunnel or VPN service full time. Most typical home/gaming computers don't deal with a lot of encrypted data streams, apart from the occasional password hash or https header whenever you log into something.
Servers, on the other hand... and Epic is saying they are seeing a lot of issues on their cloud servers for Fortnite right now.
https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update?p=132713#post132713
Another good explanation, from the fellow that brought you the Raspberry Pi (which are immune to these attacks, btw).
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
Encrypting and decrypting data is just software, so the patch shouldn't affect the speed of that. Nor should it affect the performance of changing file formats. A VPN might be a problem depending on how often it is forced to do system calls, but I suspect that it won't be a big deal.
If you're doing database work where the database is large enough that you can't keep it in memory and it's a ton of very small file I/O, then that could be a problem. Having a ton of very short system calls so that you have to constantly switch between user memory and kernel memory will impose a considerable hit every time you switch.
Well a friends company has taken their VM machines and VPN's off the net entirely. It does take data longer to get into the system because of this, but with files of millions of users they just cannot take any kind of a performance hit.
Windows 10 is slowed down less than Windows 8 and Windows 7
Intels' Skylake processors and later (6000 series and later) is slowed down less than earlier Intel processors.
If you're using Windows 10 and modern processor the slowdown should be only single digit and most users won't notice anything. If you're unlucky and are using older OS + older processor the slowdown will be so large that most users will notice decreased performance.
There are two updates required for the security fixes: One for the OS, one for processor microcode. Most of the current slowdown benchmarks are done with only one of those updates, and don't show the full truth of how much the computer will be slowed down.
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/
Brenics ~ Just to point out I do believe Chris Roberts is going down as the man who cheated backers and took down crowdfunding for gaming.