Guru3D Thermal Paste Roundup 2019
Back-to-school Microsoft Office 2016 $18 Win 10 Pro $12
TeamGroup T-Force Vulcan 1TB SSD Review
Corsair K57 RGB Wireless keyboard review
AMD Ryzen 7 3800X review
PowerColor 5700 RED DEVIL review
MSI Radeon RX 5700 XT Evoke review
ASUS Radeon RX 5700 XT ROG STRIX review
ViewSonic Elite XG240R Monitor Review
Promo: URCDKey Summer Sale Windows 10 Pro for $11
AMD Security Statement from CTO and SVP Mark Papermaster
AMD have updated their web page and clarified a bit more on speculative_execution vulnerabilities with some additional details on current state of affairs and AMD actions.
--- AMD ---
An Update on AMD Processor Security
The public disclosure on January 3rd that multiple research teams had discovered security issues related to how modern microprocessors handle speculative execution has brought to the forefront the constant vigilance needed to protect and secure data. These threats seek to circumvent the microprocessor architecture controls that preserve secure data.
At AMD, security is our top priority and we are continually working to ensure the safety of our users as new risks arise. As a part of that vigilance, I wanted to update the community on our actions to address the situation.
- Google Project Zero (GPZ) Variant 1 (Bounds Check Bypass or Spectre) is applicable to AMD processors.
- We believe this threat can be contained with an operating system (OS) patch and we have been working with OS providers to address this issue.
- Microsoft is distributing patches for the majority of AMD systems now. We are working closely with them to correct an issue that paused the distribution of patches for some older AMD processors (AMD Opteron, Athlon and AMD Turion X2 Ultra families) earlier this week. We expect this issue to be corrected shortly and Microsoft should resume updates for these older processors by next week. For the latest details, please see Microsoft’s website.
- Linux vendors are also rolling out patches across AMD products now.
- GPZ Variant 2 (Branch Target Injection or Spectre) is applicable to AMD processors.
- While we believe that AMD’s processor architectures make it difficult to exploit Variant 2, we continue to work closely with the industry on this threat. We have defined additional steps through a combination of processor microcode updates and OS patches that we will make available to AMD customers and partners to further mitigate the threat.
- AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to make updates available for our previous generation products over the coming weeks. These software updates will be provided by system providers and OS vendors; please check with your supplier for the latest information on the available option for your configuration and requirements.
- Linux vendors have begun to roll out OS patches for AMD systems, and we are working closely with Microsoft on the timing for distributing their patches. We are also engaging closely with the Linux community on development of “return trampoline” (Retpoline) software mitigations.
- GPZ Variant 3 (Rogue Data Cache Load or Meltdown) is not applicable to AMD processors.
- We believe AMD processors are not susceptible due to our use of privilege level protections within paging architecture and no mitigation is required.
There have also been questions about GPU architectures. AMD Radeon GPU architectures do not use speculative execution and thus are not susceptible to these threats.
We will provide further updates as appropriate on this site as AMD and the industry continue our collaborative work to develop mitigation solutions to protect users from these latest security threats.
Mark Papermaster,
Senior Vice President and Chief Technology Officer
schmidtbag
Senior Member
Posts: 4264
Joined: 2012-11-10
Senior Member
Posts: 4264
Joined: 2012-11-10
#5510111 Posted on: 01/12/2018 04:46 PM
So basically just Variant 2 is noteworthy (but not necessarily crucial).
At least a high-up representative from AMD finally gave a solid answer. I was getting a bit tired of all the pussyfooting AMD was doing for the past couple weeks.
So basically just Variant 2 is noteworthy (but not necessarily crucial).
At least a high-up representative from AMD finally gave a solid answer. I was getting a bit tired of all the pussyfooting AMD was doing for the past couple weeks.
nevcairiel
Senior Member
Posts: 580
Joined: 2015-05-19
Senior Member
Posts: 580
Joined: 2015-05-19
#5510288 Posted on: 01/13/2018 12:19 AM
Didn't AMD basically start with "We're not affected" when the news first broke? Long way to go from "not" to two variants actually being applicable. Sure, Meltdown is Intel only, but Spectre might be as bad or possibly even worse in the long run.
Didn't AMD basically start with "We're not affected" when the news first broke? Long way to go from "not" to two variants actually being applicable. Sure, Meltdown is Intel only, but Spectre might be as bad or possibly even worse in the long run.
D3M1G0D
Senior Member
Posts: 1804
Joined: 2017-03-10
Senior Member
Posts: 1804
Joined: 2017-03-10
#5510289 Posted on: 01/13/2018 12:23 AM
No, it isn't. Meltdown is by far the scariest CPU bug I have ever seen - Spectre comes nowhere close to it.
Didn't AMD basically start with "We're not affected" when the news first broke? Long way to go from "not" to two variants actually being applicable. Sure, Meltdown is Intel only, but Spectre might be as bad or possibly even worse in the long run.
No, it isn't. Meltdown is by far the scariest CPU bug I have ever seen - Spectre comes nowhere close to it.
schmidtbag
Senior Member
Posts: 4264
Joined: 2012-11-10
Senior Member
Posts: 4264
Joined: 2012-11-10
#5510294 Posted on: 01/13/2018 12:34 AM
I don't recall AMD saying they weren't affected, though as I mentioned in my last post, they seemed to be intentionally vague about all of this. What I remember is they were being dismissive of its severity. To be fair, they weren't totally wrong in doing so - from what I heard, you need physical access to the system to exploit the bug (on AMD), in which case the user would have bigger things to worry about. At least in Linux, they seem to add patches that would exclude them in some of the recent kernel bug fixes. It's all a bit difficult to keep track of, but at least today we finally have a more clear answer.
Didn't AMD basically start with "We're not affected" when the news first broke? Long way to go from "not" to two variants actually being applicable. Sure, Meltdown is Intel only, but Spectre might be as bad or possibly even worse in the long run.
I don't recall AMD saying they weren't affected, though as I mentioned in my last post, they seemed to be intentionally vague about all of this. What I remember is they were being dismissive of its severity. To be fair, they weren't totally wrong in doing so - from what I heard, you need physical access to the system to exploit the bug (on AMD), in which case the user would have bigger things to worry about. At least in Linux, they seem to add patches that would exclude them in some of the recent kernel bug fixes. It's all a bit difficult to keep track of, but at least today we finally have a more clear answer.
nevcairiel
Senior Member
Posts: 580
Joined: 2015-05-19
Senior Member
Posts: 580
Joined: 2015-05-19
#5510310 Posted on: 01/13/2018 01:11 AM
Thats the "simple" view of it. Both achieve the same thing, leaking information. Meltdown is easier to exploit and more of a straight-forward bug in the CPUs in question. However, Spectre is not a "bug" as such, but a fundamental concept of any speculative execution on CPUs (so basically, any modern CPU across vendors and architectures) - which makes Spectre far more scary in the long run from the sheer scale of it. Its also much harder to fully mitigate (if even at all without fundamental hardware design changes). The fact alone that Spectre basically effects all modern CPUs, from x86 to ARM, POWER and who knows what else should scare you.
No, it isn't. Meltdown is by far the scariest CPU bug I have ever seen - Spectre comes nowhere close to it.
Thats the "simple" view of it. Both achieve the same thing, leaking information. Meltdown is easier to exploit and more of a straight-forward bug in the CPUs in question. However, Spectre is not a "bug" as such, but a fundamental concept of any speculative execution on CPUs (so basically, any modern CPU across vendors and architectures) - which makes Spectre far more scary in the long run from the sheer scale of it. Its also much harder to fully mitigate (if even at all without fundamental hardware design changes). The fact alone that Spectre basically effects all modern CPUs, from x86 to ARM, POWER and who knows what else should scare you.
D3M1G0D
Senior Member
Posts: 1804
Joined: 2017-03-10
Senior Member
Posts: 1804
Joined: 2017-03-10
#5510313 Posted on: 01/13/2018 01:22 AM
I don't see much of a threat from Spectre. Unlike Meltdown, the ability to get useful, sensitive data is extremely rare, and there are ways to mitigate it through software and preemptive coding (speaking as a professional computer programmer, it won't take that much work to redesign for it). Combine that with OS patches and/or BIOS updates and I don't see it as a major threat.
Like I said, Meltdown is the scariest bug I have ever seen, breaking down any and all security checks and able to read reams of sensitive data. Spectre is more pervasive but far less dangerous, and I won't lose any sleep over it.
Thats the "simple" view of it. Both achieve the same thing, leaking information. Meltdown is easier to exploit and more of a straight-forward bug in the CPUs in question. However, Spectre is not a "bug" as such, but a fundamental concept of any speculative execution on CPUs (so basically, any modern CPU across vendors and architectures) - which makes Spectre far more scary in the long run from the sheer scale of it. Its also much harder to fully mitigate (if even at all without fundamental hardware design changes). The fact alone that Spectre basically effects all modern CPUs, from x86 to ARM, POWER and who knows what else should scare you.
I don't see much of a threat from Spectre. Unlike Meltdown, the ability to get useful, sensitive data is extremely rare, and there are ways to mitigate it through software and preemptive coding (speaking as a professional computer programmer, it won't take that much work to redesign for it). Combine that with OS patches and/or BIOS updates and I don't see it as a major threat.
Like I said, Meltdown is the scariest bug I have ever seen, breaking down any and all security checks and able to read reams of sensitive data. Spectre is more pervasive but far less dangerous, and I won't lose any sleep over it.
fantaskarsef
Senior Member
Posts: 10588
Joined: 2014-07-21
Senior Member
Posts: 10588
Joined: 2014-07-21
#5510738 Posted on: 01/15/2018 09:00 AM
Those security flaws wouldn't be scary at all if they were patched right away properly, not half heartedly and technically lacking like with AMD systems and their non-bootability issues, not producing random reboots in Haswell systems, and that's just what we know so far. We've yet to see any real exploit, and so far (if you don't consider the possible damage) all we've got from this is a slow down of systems and more borken patches / updates.
Those security flaws wouldn't be scary at all if they were patched right away properly, not half heartedly and technically lacking like with AMD systems and their non-bootability issues, not producing random reboots in Haswell systems, and that's just what we know so far. We've yet to see any real exploit, and so far (if you don't consider the possible damage) all we've got from this is a slow down of systems and more borken patches / updates.
schmidtbag
Senior Member
Posts: 4264
Joined: 2012-11-10
Senior Member
Posts: 4264
Joined: 2012-11-10
#5510839 Posted on: 01/15/2018 04:09 PM
I'm not sure you fully understand this situation.
Considering how long these issues were known, I agree it took a little too long to patch the problems. However, the issues with Haswells and outdated AMD CPUs is something I would rather blame on Microsoft. To my knowledge, other OSes aren't getting these issues.
But more importantly, slow downs aren't a side effect of these patches - slow downs are the sacrifice of these patches. The performance loss was predicted before anyone even tested it. That's because the security risk itself was designed to improve performance. So, the only way to quickly and effectively protect users from this bug is to simply disable speculative execution, and therefore the losses associated with it.
Those security flaws wouldn't be scary at all if they were patched right away properly, not half heartedly and technically lacking like with AMD systems and their non-bootability issues, not producing random reboots in Haswell systems, and that's just what we know so far. We've yet to see any real exploit, and so far (if you don't consider the possible damage) all we've got from this is a slow down of systems and more borken patches / updates.
I'm not sure you fully understand this situation.
Considering how long these issues were known, I agree it took a little too long to patch the problems. However, the issues with Haswells and outdated AMD CPUs is something I would rather blame on Microsoft. To my knowledge, other OSes aren't getting these issues.
But more importantly, slow downs aren't a side effect of these patches - slow downs are the sacrifice of these patches. The performance loss was predicted before anyone even tested it. That's because the security risk itself was designed to improve performance. So, the only way to quickly and effectively protect users from this bug is to simply disable speculative execution, and therefore the losses associated with it.
fantaskarsef
Senior Member
Posts: 10588
Joined: 2014-07-21
Senior Member
Posts: 10588
Joined: 2014-07-21
#5511051 Posted on: 01/16/2018 08:15 AM
I'm not sure you fully understand this situation.
Considering how long these issues were known, I agree it took a little too long to patch the problems. However, the issues with Haswells and outdated AMD CPUs is something I would rather blame on Microsoft. To my knowledge, other OSes aren't getting these issues.
But more importantly, slow downs aren't a side effect of these patches - slow downs are the sacrifice of these patches. The performance loss was predicted before anyone even tested it. That's because the security risk itself was designed to improve performance. So, the only way to quickly and effectively protect users from this bug is to simply disable speculative execution, and therefore the losses associated with it.
Well, I am fairly aware that the issues here come from the way that Intel's chips "predict" usage in the first place, so thanks for your consideration. I've read the links posted here by others (you iirc too).
Then again, deactivating those speculative executions does not make a system not boot or reboot unprovoced by the user.
By the way, google has found a software resolution with marginal performance impact on their server systems while still keeping their systems secure.
https://www.blog.google/topics/google-cloud/protecting-our-google-cloud-customers-new-vulnerabilities-without-impacting-performance/
I'm not sure you fully understand this situation.
Considering how long these issues were known, I agree it took a little too long to patch the problems. However, the issues with Haswells and outdated AMD CPUs is something I would rather blame on Microsoft. To my knowledge, other OSes aren't getting these issues.
But more importantly, slow downs aren't a side effect of these patches - slow downs are the sacrifice of these patches. The performance loss was predicted before anyone even tested it. That's because the security risk itself was designed to improve performance. So, the only way to quickly and effectively protect users from this bug is to simply disable speculative execution, and therefore the losses associated with it.
Well, I am fairly aware that the issues here come from the way that Intel's chips "predict" usage in the first place, so thanks for your consideration. I've read the links posted here by others (you iirc too).
Then again, deactivating those speculative executions does not make a system not boot or reboot unprovoced by the user.
By the way, google has found a software resolution with marginal performance impact on their server systems while still keeping their systems secure.
https://www.blog.google/topics/google-cloud/protecting-our-google-cloud-customers-new-vulnerabilities-without-impacting-performance/
schmidtbag
Senior Member
Posts: 4264
Joined: 2012-11-10
Senior Member
Posts: 4264
Joined: 2012-11-10
#5511153 Posted on: 01/16/2018 03:32 PM
Well, that's why disabling this feature results in performance losses. So far, most of the performance losses have been very minimal - seems to me that just tasks that are both heavy in I/O and CPU load take the hardest hits, but otherwise everything seems to be less than a 5% loss.
That's true - it shouldn't do that. This is why it's specifically a MS issue, since Linux and FreeBSD (which, for the record, have independently made their own patches) are not known to have issues.
Well, I am fairly aware that the issues here come from the way that Intel's chips "predict" usage in the first place, so thanks for your consideration. I've read the links posted here by others (you iirc too).
Well, that's why disabling this feature results in performance losses. So far, most of the performance losses have been very minimal - seems to me that just tasks that are both heavy in I/O and CPU load take the hardest hits, but otherwise everything seems to be less than a 5% loss.
Then again, deactivating those speculative executions does not make a system not boot or reboot unprovoced by the user.
That's true - it shouldn't do that. This is why it's specifically a MS issue, since Linux and FreeBSD (which, for the record, have independently made their own patches) are not known to have issues.
Click here to post a comment for this news story on the message forum.
Senior Member
Posts: 876
Joined: 2014-11-19
Thanks HH.