Info Meltdown and Spectre Vulnerabilities Information

[goldstone77]

It's looking bad for the microcode patch . Talk of significant performance hit with SSDs.

Edit: Don't forget the reddit post https://np.reddit.com/r/pcmasterrace/comments/7obokl/performance_impact_of_windows_patch_and_bios/

 

[goldstone77]

My question is, what if tomorrow a Meltdown attack is successful on AMD chips? All AMD systems will be insecure.

I talked about it here http://www.tomshardware.com/forum/id-3609004/cpu-security-vulnerabilities-information.html#20556178

- Exclude AMD from the PTI enforcement. Not necessarily a fix, but if
AMD is so confident that they are not affected, then we should not
burden users with the overhead"

I talked about it again here
http://www.tomshardware.com/forum/id-3609004/cpu-security-vulnerabilities-information.html#20557957
I show why we should take AMD's word for it.

However, despite its simplicity, it is used as
a basis for Section 4 and Section 5, where we show how
this change in state can be exploited for an attack.

This is proof of "concept" and they admit the inability to execute.

6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
out-of-order execution pipeline could tip the race
condition towards against the data leakage. Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.

AMD's response:

"Our CPUs don't speculate using memory references pointing to locations restricted to higher privilege levels than the running code"

We have no reason to not take AMD's word for it. But if it is proven that it's possible to exploit they will have some crow to eat!
And again here
http://www.tomshardware.com/forum/id-3609004/cpu-security-vulnerabilities-information.html#20558011

Variant Three Rogue Data Cache Load Zero AMD vulnerability due to AMD architecture differences.

AMD's security page showing Meltdown

https://www.amd.com/en/corporate/speculative-execution

 

[juanrga]

I know that AMD claims its CPUs aren't affected. I am quoting the researchers that discovered this and that don't share AMD PR statements. Nowhere the researchers claim "inability to execute". At contrary. in the part after the one that you bolded thay state that its proof-of-concept also works for AMD and ARM: "However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.".

 

[goldstone77]

I know that AMD claims its CPUs aren't affected. I am quoting the researchers that discovered this and that don't share AMD PR statements. Nowhere the researchers claim "inability to execute". At contrary. in the part after the one that you bolded thay state that its proof-of-concept also works for AMD and ARM: "However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.".

Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data.

They never dispute AMD's claims at all, this statement is made referring to the experiment. Which, they admit they don't know why the exploit doesn't work on several processors, and it could be that they are not vulnerable at all. Proof of concept is not proof that it works! AMD's makes it's claims after the experiment when confronted with the test. And like I said there is not reason to refute AMD's arguments until proven otherwise like stated by Linus Torvalds. Please use spoilers when referring to past arguments, so other may follow the thread more easily.

Edit: Just to summit it up, if they can't prove it works why try to use circumvent it using a method they can't prove is exploitable? They would be adding overhead for no reason. If it's exploitable by another method, different counter measures would be needed anyway!

 

[juanrga]

They never dispute AMD's claims at all

They do in the official Meltdown site.

At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

What is more, Red-Hat security expertise also raises doubts about AMD claims:

Those reading media accounts published Wednesday and Thursday are probably under the impression that while Spectre affects Intel, AMD and ARM CPUs, that Meltdown affects only Intel products -- or perhaps all Intel CPUs and some ARM chips.

Not so, says Red Hat's Jon Masters. Both vulnerabilities are basically architecture agnostic.

"I think Intel got a lot of unfair attention this week," Masters told Data Center Knowledge. "The reality is that it's a cross industry, cross vendor issue that affects pretty much every architecture. It's not just Intel, AMD and ARM, it's actually every modern architecture."

 

[goldstone77]

They never dispute AMD's claims at all

They do in the official Meltdown site.

At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

What is more, Red-Hat security expertise also raises doubts about AMD claims:

Those reading media accounts published Wednesday and Thursday are probably under the impression that while Spectre affects Intel, AMD and ARM CPUs, that Meltdown affects only Intel products -- or perhaps all Intel CPUs and some ARM chips.

Not so, says Red Hat's Jon Masters. Both vulnerabilities are basically architecture agnostic.

"I think Intel got a lot of unfair attention this week," Masters told Data Center Knowledge. "The reality is that it's a cross industry, cross vendor issue that affects pretty much every architecture. It's not just Intel, AMD and ARM, it's actually every modern architecture."

You are repeating the same rhetoric over and over now not adding any proof that the exploit works, so the argument is pointless. I offered proof the tester don't know if the attack is even possible. https://meltdownattack.com/meltdown.pdf is the paper of the test performed. quotes from the paper that I've already posted repeatedly:

6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold. First of all, our implementation
might simply be too slow and a more optimized
version might succeed. For instance, a more shallow
out-of-order execution pipeline could tip the race
condition towards against the data leakage. Similarly,
if the processor lacks certain features, e.g., no re-order
buffer, our current implementation might not be able to
leak data. However, for both ARM and AMD, the toy
example as described in Section 3 works reliably, indicating
that out-of-order execution generally occurs and
instructions past illegal memory accesses are also performed.

Like I said before proof of concept does not mean it's exploitable by the method they are using, and they admit that. And if another method allows the exploit different counter measures would have to be deployed. So, again like Linus Torvalds says why add the overhead if AMD is sure it doesn't affect them! Again, AMD was presented with the lack of evidence of a successfully method of delivering the exploit, and thus their security statement! Unless you have proof to the contrary why argue otherwise? You are presenting he said she said argument with it might be possible, but it might not be possible at all! Without proof it's a dead end argument in AMD favor.

 

[jankerson]

Windows 7 Pro update available and installed through Windows Update today.

 

[goldstone77]

Epic Services & Stability Update
Yesterday, 06:49 PM

Attention Fortnite community,

We wanted to provide a bit more context for the most recent login issues and service instability. All of our cloud services are affected by updates required to mitigate the Meltdown vulnerability. We heavily rely on cloud services to run our back-end and we may experience further service issues due to ongoing updates.

Here is a link to an article which describes the issue in depth.

The following chart shows the significant impact on CPU usage of one of our back-end services after a host was patched to address the Meltdown vulnerability.

Unexpected issues may occur with our services over the next week as the cloud services we use are updated. We are working with our cloud service providers to prevent further issues and will do everything we can to mitigate and resolve any issues that arise as quickly as possible. Thank you all for understanding. Follow our twitter @FortniteGame for any future updates regarding this issue.

Epic suggests following security best practices by always staying up to date with latest patches.
General Recommendations for Computer Security

We will continue to update this thread with similar information as it comes to us.

 

[Darkbreeze]

On another note, it seems we suddenly have had a rash of user drives SMART reporting failures. Any chance this is something related to any of these patches/microcode updates? I don't know whether SMART would be affected by the suppression of branch prediction or not, but it seems at least minimally plausible. Just wondered if anybody had seen any evidence of this.

 

[jankerson]

On another note, it seems we suddenly have had a rash of user drives SMART reporting failures. Any chance this is something related to any of these patches/microcode updates? I don't know whether SMART would be affected by the suppression of branch prediction or not, but it seems at least minimally plausible. Just wondered if anybody had seen any evidence of this.

No SMART issues on any of the 3 machines I have after the update.

 

[goldstone77]

AMD Did NOT Disable Branch Prediction With A Zen Microcode Update
Written by Michael Larabel in AMD on 6 January 2018 at 07:02 AM EST.

With the plethora of software security updates coming out over the past few days in the wake of the Meltdown and Spectre disclosure, released by SUSE was a Family 17h "Zen" CPU microcode update that we have yet to see elsewhere... It claims to disables branch prediction, but I've confirmed with AMD that is not actually the case.

AMD did post a processor security notice where they noted their hardware was not vulnerable to variant threee / rogue data cache load, for the "branch target injection" variant that there was "near zero risk" for exploiting, and with the bounds check bypass it would be resolved by software/OS updates.

Along with the Linux kernel patches for enabling KPTI (Page Table Isolation), SUSE issued a security bulletin where they added an AMD microcode update. The bulletin mentions, "This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory." The AMD change-log does note this AMD microcode update is indeed for CVE-2017-5715, a.k.a. SPECTRE.

But surprisingly I have yet to see any other Linux distribution vendors promoting this new microcode_amd_fam17h.bin microcode file for disabling branch prediction on these latest AMD Ryzen/Threadripper/EPYC processors. This new Family 17h microcode file also hasn't been added as of writing to the linux-firmware.git tree.

I reached out to AMD and on Friday heard back. They wrote in an email to Phoronix that this Zen/17h microcode update does not disable branch prediction. They'll be working with SUSE to re-clarify this microcode update description... But as far as what this microcode update does in the wake of SPECTRE they have yet to clarify or why this microcode binary has yet to make it to other Linux distributions. If/when I hear anything more, I'll certainly post about it but doesn't appear to be anything as dramatic as disabling branch prediction, which could have slaughtered their CPU performance.

 

[goldstone77]

Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables
Updated Friday at 10:30 PM
https://access.redhat.com/articles/3311301

Architectural Defaults
By default, each of the 3 tunables that apply to an architecture will be enabled automatically at boot time, based upon the architecture detected.

Intel Defaults:

pti 1 ibrs 1 ibpb 1 -> fix variant#1 #2 #3
pti 1 ibrs 0 ibpb 0 -> fix variant#1 #3 (for older Intel systems with no microcode update available)

AMD Defaults:
Due to the differences in underlying hardware implementation, AMD X86 systems are not vulnerable to variant #3. The correct default values will be set on AMD hardware based on dynamic checks during the boot sequence.

pti 0 ibrs 0 ibpb 2 -> fix variant #1 #2 if the microcode update is applied
pti 0 ibrs 2 ibpb 1 -> fix variant #1 #2 on older processors that can disable indirect branch prediction without microcode updates

Edit: Added picture for clarity

 

[joealfano11]

So are Operating Systems such as Windows with there soon coming updates basically trying to put a band-aid on the problem until Intel and AMD release processors that do not have this gaping vulnerability? If this is the case, potential hackers can break into the band-aid placed by operating systems and cause major issues not really with AMD but more with Intel. Right?

 

[goldstone77]

So are Operating Systems such as Windows with there soon coming updates basically trying to put a band-aid on the problem until Intel and AMD release processors that do not have this gaping vulnerability? If this is the case, potential hackers can break into the band-aid placed by operating systems and cause major issues not really with AMD but more with Intel. Right?

The 2 exploits are made up of 3 variants. 1 and 2 for Spectre, and 3 for Meltdown. All three expose hardware level vulnerabilities. At this time we know all three attacks are successful on Intel CPUs. So far only attacks 1 and 2 are successful on AMD CPUs. There are OS software updates, and microcode bios updates for motherboards to help prevent the know methods of exploiting these vulnerabilities. Spectre is a low level hardware security flaws that will be difficult to redesign in order to permanently fix, which may take years. These attacks only allow the hacker to steal privileged information without leaving a log of the event. But some of that privileged information may lead to the hacker successfully gaining access to passwords or other information that might allow further hacking to be possible. The Spectre methods are extremely difficult to exploit, even by an app running locally, they can be potentially exploited in JavaScript running in a web browser.

 

[goldstone77]

Woo-yay, Meltdown CPU fixes are here. Now, Spectre flaws will haunt tech industry for years
Countermeasures to protect apps from attack
By Thomas Claburn in San Francisco 5 Jan 2018 at 07:08
https://www.theregister.co.uk/2018/01/05/spectre_flaws_explained/
The article lays out a good timeline, and describes the attacks in good detail.

 

[goldstone77]

Meltdown & Spectre Updates Benchmarked, Big Slow Down for SSDs!
Hardware Unboxed
Published on Jan 6, 2018
[video="https://www.youtube.com/watch?v=JbhKUjPRk5Q&feature=youtu.be"][/video]

Not much impact on gaming or application performance, but NVME and SSDs take another hit in performance.

 

[juanrga]

AMD Did NOT Disable Branch Prediction With A Zen Microcode Update
Written by Michael Larabel in AMD on 6 January 2018 at 07:02 AM EST.

With the plethora of software security updates coming out over the past few days in the wake of the Meltdown and Spectre disclosure, released by SUSE was a Family 17h "Zen" CPU microcode update that we have yet to see elsewhere... It claims to disables branch prediction, but I've confirmed with AMD that is not actually the case.

AMD did post a processor security notice where they noted their hardware was not vulnerable to variant threee / rogue data cache load, for the "branch target injection" variant that there was "near zero risk" for exploiting, and with the bounds check bypass it would be resolved by software/OS updates.

Along with the Linux kernel patches for enabling KPTI (Page Table Isolation), SUSE issued a security bulletin where they added an AMD microcode update. The bulletin mentions, "This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory." The AMD change-log does note this AMD microcode update is indeed for CVE-2017-5715, a.k.a. SPECTRE.

But surprisingly I have yet to see any other Linux distribution vendors promoting this new microcode_amd_fam17h.bin microcode file for disabling branch prediction on these latest AMD Ryzen/Threadripper/EPYC processors. This new Family 17h microcode file also hasn't been added as of writing to the linux-firmware.git tree.

I reached out to AMD and on Friday heard back. They wrote in an email to Phoronix that this Zen/17h microcode update does not disable branch prediction. They'll be working with SUSE to re-clarify this microcode update description... But as far as what this microcode update does in the wake of SPECTRE they have yet to clarify or why this microcode binary has yet to make it to other Linux distributions. If/when I hear anything more, I'll certainly post about it but doesn't appear to be anything as dramatic as disabling branch prediction, which could have slaughtered their CPU performance.

Michael forgot to add that the info was given to him by a PR guy.

Since Spectre mechanism for triggering is speculative execution from branch prediction, the attack affects all CPUs that perform speculative execution from branch prediction. So it seems obvious that one has to disable branch prediction on CPUs to prevent the attack. And that is just what the Spectre patch does, at the expense of performance

- CVE-2017-5715: Local attackers on systems with modern CPUs featuring
branch prediction could use mispredicted branches to speculatively
execute code patterns that in turn could be made to leak other
non-readable content in the same address space, an attack similar to
CVE-2017-5753.

This problem is mitigated by disabling predictive branches, depending
on CPU architecture either by firmware updates and/or fixes in the
user-kernel privilege boundaries.

This is done with help of Linux Kernel fixes on the Intel/AMD x86_64 and
IBM zSeries architectures. On x86_64, this requires also updates of the
CPU microcode packages, delivered in seperate updates.

For IBM Power and zSeries the required firmware updates are supplied
over regular channels by IBM.

As this feature can have a performance impact, it can be disabled using
the "nospec" kernel commandline option.

https://www.suse.com/es-es/support/update/announcement/2018/suse-su-20180011-1/

 

[juanrga]

More benches

https://www.gamersnexus.net/guides/3194-intel-windows-security-patch-bench-this-article-is-pointless

 

[goldstone77]

More benches

https://www.gamersnexus.net/guides/3194-intel-windows-security-patch-bench-this-article-is-pointless

Just note that these benches are just the windows patch. The firmware microcode bios update has a 0-3% effect on fps and up to 40% reduction in read and write speeds on NVME drives during some synthetic benchmarks. So it looks like servers will be mostly affected by this, but more testing needs to be done as the microcode updates start rolling out. Epic games has releases a response after one of their servers received the meltdown patch. Complaints started rolling in like the first one:

What this doesn't tell me is if it's gonna be possible go log in sometime soon.
I've got research points that need collecting.

I wonder what will happen after they patch the other 2 servers, and then receive the Spectre patch.
Epic Services & Stability Update
01-05-2018, 06:49 PM
https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update

 

[goldstone77]

Spoiler

AMD Did NOT Disable Branch Prediction With A Zen Microcode Update
Written by Michael Larabel in AMD on 6 January 2018 at 07:02 AM EST.

With the plethora of software security updates coming out over the past few days in the wake of the Meltdown and Spectre disclosure, released by SUSE was a Family 17h "Zen" CPU microcode update that we have yet to see elsewhere... It claims to disables branch prediction, but I've confirmed with AMD that is not actually the case.

AMD did post a processor security notice where they noted their hardware was not vulnerable to variant threee / rogue data cache load, for the "branch target injection" variant that there was "near zero risk" for exploiting, and with the bounds check bypass it would be resolved by software/OS updates.

Along with the Linux kernel patches for enabling KPTI (Page Table Isolation), SUSE issued a security bulletin where they added an AMD microcode update. The bulletin mentions, "This new firmware disables branch prediction on AMD family 17h processor to mitigate a attack on the branch predictor that could lead to information disclosure from e.g. kernel memory." The AMD change-log does note this AMD microcode update is indeed for CVE-2017-5715, a.k.a. SPECTRE.

But surprisingly I have yet to see any other Linux distribution vendors promoting this new microcode_amd_fam17h.bin microcode file for disabling branch prediction on these latest AMD Ryzen/Threadripper/EPYC processors. This new Family 17h microcode file also hasn't been added as of writing to the linux-firmware.git tree.

I reached out to AMD and on Friday heard back. They wrote in an email to Phoronix that this Zen/17h microcode update does not disable branch prediction. They'll be working with SUSE to re-clarify this microcode update description... But as far as what this microcode update does in the wake of SPECTRE they have yet to clarify or why this microcode binary has yet to make it to other Linux distributions. If/when I hear anything more, I'll certainly post about it but doesn't appear to be anything as dramatic as disabling branch prediction, which could have slaughtered their CPU performance.

Michael forgot to add that the info was given to him by a PR guy.

Since Spectre mechanism for triggering is speculative execution from branch prediction, the attack affects all CPUs that perform speculative execution from branch prediction. So it seems obvious that one has to disable branch prediction on CPUs to prevent the attack. And that is just what the Spectre patch does, at the expense of performance

- CVE-2017-5715: Local attackers on systems with modern CPUs featuring
branch prediction could use mispredicted branches to speculatively
execute code patterns that in turn could be made to leak other
non-readable content in the same address space, an attack similar to
CVE-2017-5753.

This problem is mitigated by disabling predictive branches, depending
on CPU architecture either by firmware updates and/or fixes in the
user-kernel privilege boundaries.

This is done with help of Linux Kernel fixes on the Intel/AMD x86_64 and
IBM zSeries architectures. On x86_64, this requires also updates of the
CPU microcode packages, delivered in seperate updates.

For IBM Power and zSeries the required firmware updates are supplied
over regular channels by IBM.

As this feature can have a performance impact, it can be disabled using
the "nospec" kernel commandline option.

https://www.suse.com/es-es/support/update/announcement/2018/suse-su-20180011-1/

If the preliminary findings for Intel's Spectre patch is any indication of the performance hit, which appears to affect NMVEs the most, by up to 40% depending on workload. It's reasonable to assume that AMD products would have a similar performance hit minus the Meltdown patch. But of course a lot more testing needs to be done.

Edit: The 40% included the windows patch, which only has about a 0-9-23% performance hit to NVME on personal computers depending on which synthetic benchmark was used.

2nd Edit: Look at the comment I made it shows how AMD and Intel are patching using IBRS and IPBP in the kernel. Intel and AMD are adding the same controls for Spectre at the kernel. Note the defaults show no fix for older systems for variant 2 on Intel systems. I think Intel and AMD will still run into the same problem for personal computers on older systems. Motherboard manufacturers only have to support a motherboard for the length of its warranty? 1-3 years...
Controlling the Performance Impact of Microcode and Security Patches for CVE-2017-5754 CVE-2017-5715 and CVE-2017-5753 using Red Hat Enterprise Linux Tunables
Updated Friday at 10:30 PM
https://access.redhat.com/articles/3311301
http://www.tomshardware.com/forum/id-3609004/cpu-security-vulnerabilities-information/page-3.html#20566795

 

[Deleted member 217926]

Looks like NVMe storage is taking a pretty big hit with this 'fix' at least on Asus boards.

https://www.techspot.com/article/1556-meltdown-and-spectre-cpu-performance-windows/page3.html

I've got a 950 Pro so yay. Gigabyte board though. No BIOS updates yet.

SATA drives also take a hit.

 

[goldstone77]

Looks like NVMe storage is taking a pretty big hit with this 'fix' at least on Asus boards.

https://www.techspot.com/article/1556-meltdown-and-spectre-cpu-performance-windows/page3.html

I've got a 950 Pro so yay. Gigabyte board though. No BIOS updates yet.

SATA drives also take a hit.

From the looks of it the windows update had 0-23% degradation in NVME performance, after jumped that to 41% depending on workload.

Then we get to the 512K write test and what’s gone wrong here, a 41% reduction in performance can be see and this wasn’t a once off deal.

Servers will not like this microcode fix! Because of the inconsistency in performance from various workloads. It's going to take more testing to find out how this affect different server workloads. Imagine waking up and finding out you need to buy ~40% more infrastructure...

 

[gamerk316]

And now AMD CPUs management engine has a security hole:

https://www.theregister.co.uk/2018/01/06/amd_cpu_psp_flaw/

 

[goldstone77]

And now AMD CPUs management engine has a security hole:

https://www.theregister.co.uk/2018/01/06/amd_cpu_psp_flaw/

Yeah, Juanrga posted something about a stack overflow vulnerability for the psp that was patched in december. This is about the same exploit. Here are what I thought were some of the key takeaways.

This sounds bad. It's not as bad as you think.

Unlike some CPUs, the PSP doesn't implement common exploit mitigation techniques such as stack cookies, No-eXecute (NX) flags, or address space layout randomization (ASLR), making exploitation trivial.

Cohen's post described the vulnerability as remote code execution flaw. However, physical access is a prerequisite.

the attacker must already have privileged access to the host or physical access. It would let an attacker bypass secure/trusted boot, which is performed by the TPM."

An AMD spokesperson told The Register that an attacker would first have to gain access to the motherboard and then modify SPI-Flash before the issue could be exploited. But given those conditions, the attacker would have access to the information protected by the TPM, such as cryptographic keys.

AMD's spokesperson said the chipmaker plans to address the vulnerability for a limited number of firmware versions. BIOS updates from OEMs are supposed to be made available later this month.

If anyone wants to read more about PSP

As AMD explains it, the PSP – referred to as AMD Secure Technology – monitors the security environment for the processor, managing the boot process, initializing security mechanisms, and checking for suspect activity. It is described in detail from page 156 of this official developer manual.

BIOS and Kernel
Developer’s Guide
(BKDG)
for AMD Family 16h
Models 30h-3Fh
Processors
http://support.amd.com/TechDocs/52740_16h_Models_30h-3Fh_BKDG.pdf

 

[antoniointini]

Guys, noob question here, I heard from several sources something about a major patch coming tomorrow (tuesday). Meanwhile, I already have Microsoft's KB4056892 installed on my computers.
- Is there really another major patch expected for Tuesday, and if so, is it going to be released at OS level (such as KB4056892), or is it going to be something at BIOS level?