About speculative execution vulnerabilities in ARM-based and Intel CPUs(support.apple.com)
support.apple.com
About speculative execution vulnerabilities in ARM-based and Intel CPUs
https://support.apple.com/en-us/HT208394
110 comments
I must say I am pleasantly surprised by the straightforward, no BS language
Except they forgot to tell us about older versions of macOS which probably 75%[1] of Apple users still use.
[1] http://gs.statcounter.com/macos-version-market-share/desktop...
[1] http://gs.statcounter.com/macos-version-market-share/desktop...
Security Updates were released for 10.6 and 10.5 (2017-002 and 2017-005 respectively).
Where do you see updates for 10.6 and 10.5? According to https://support.apple.com/en-us/HT208331 - there was a 2017-002 for 10.12 and a 2017-005 for 10.11.
Yes, I did mean 10.12.6 and 10.11.6.
The patch for Meltdown (CVE-2017-5754) for High Sierra, Sierra and El Capitan was contained in these security updates from December 6: https://support.apple.com/en-us/HT208331
[deleted]
Hopefully Sierra and El Capitan will get patched soon.
This statement doesn’t make it clear, but they have been patched (same fixes as High Sierra)
How were we meant to figure this out, through necromancy or something. There is no information indicating Sierra has been patched or is due to be patched.
On https://support.apple.com/en-us/HT208331 there is a reference to CVE-2017-5754 with a footnote saying "Entry added January 4, 2018" (interesting to see this "changelog" being revised as the embargo has been lifted). It says the fix is "Available for: macOS High Sierra 10.13.1, macOS Sierra 10.12.6, OS X El Capitan 10.11.6"
They edited the same page to remove those references. Best to assume Sierra and El Capitan are not patched until proven otherwise.
Clear as mud.
Clear as mud.
I am as well - this is something I can link to people who do not understand microarchitectures, so they can understand what these bugs are.
> In the coming days we plan to release mitigations in Safari to help defend against Spectre.
If Apple was able to patch macOS in the ~6 month window since the issue was discovered why were they unable to patch Safari?
Same question for Chrome and Firefox. Surely Google knew about it and hopefully they contacted Mozilla. It seems like the scope of the fixes for Chrome and Firefox are the same.
Does it really take six months to do dev & QA for a fix like this? Wasn't the plan to disclose this to the public in January anyways?
If Apple was able to patch macOS in the ~6 month window since the issue was discovered why were they unable to patch Safari?
Same question for Chrome and Firefox. Surely Google knew about it and hopefully they contacted Mozilla. It seems like the scope of the fixes for Chrome and Firefox are the same.
Does it really take six months to do dev & QA for a fix like this? Wasn't the plan to disclose this to the public in January anyways?
It was better. I'm confused how the title says Intel and ARM but the first paragraph says all processors.
> It was better. I'm confused how the title says Intel and ARM but the first paragraph says all processors.
These are the processors found in Apple products.
Yesterday, there were comments [edit: on HN] about the Intel PR announcement that were critical of the fact that Intel name-dropped AMD in what was thought to be an attempt to deflect the issue from the Intel brand.
These are the processors found in Apple products.
Yesterday, there were comments [edit: on HN] about the Intel PR announcement that were critical of the fact that Intel name-dropped AMD in what was thought to be an attempt to deflect the issue from the Intel brand.
> Our testing with public benchmarks has shown that the changes in the December 2017 updates resulted in no measurable reduction in the performance of macOS and iOS as measured by the GeekBench 4 benchmark, or in common Web browsing benchmarks such as Speedometer, JetStream, and ARES-6.
This is incredibly deceptive, because web workloads are precisely the sort not expected to be impacted by Meltdown most. As I've written elsewhere, it's syscall heavy workloads targeting fast devices, like database software on PCIe SSDs, that will suffer the greatest slowdowns.
This is incredibly deceptive, because web workloads are precisely the sort not expected to be impacted by Meltdown most. As I've written elsewhere, it's syscall heavy workloads targeting fast devices, like database software on PCIe SSDs, that will suffer the greatest slowdowns.
This spells certain doom for Apple’s vaunted supremacy in supplying high-performance hardware for database usage.
> it's syscall heavy workloads targeting fast devices, like database software on PCIe SSDs, that will suffer the greatest slowdowns.
That's not exactly a common scenario for macOS, much less iOS devices.
It's fair to call for benchmarks that are more representative of common workloads, not less representative.
That's not exactly a common scenario for macOS, much less iOS devices.
It's fair to call for benchmarks that are more representative of common workloads, not less representative.
Avid Media Composer, one of the most popular non-linear video editors in the industry, does a stat of every piece of media referenced in every project you have open when you change focus from another application back to Avid Media Composer.
Since I work on network attached storage for video editing, I'm acutely aware of how much slowing down a few simple syscalls by just a little bit can be for certain very commonly used applications on macOS.
Since I work on network attached storage for video editing, I'm acutely aware of how much slowing down a few simple syscalls by just a little bit can be for certain very commonly used applications on macOS.
> I'm acutely aware of how much slowing down a few simple syscalls by just a little bit
I'm going to go out on a limb here and say that a NAS isn't slowing things down "just a little bit". It'll be more on the order of a million times slower, for those operations.
It's always nice to keep this popular latency table in mind: http://norvig.com/21-days.html#answers
I'm going to go out on a limb here and say that a NAS isn't slowing things down "just a little bit". It'll be more on the order of a million times slower, for those operations.
It's always nice to keep this popular latency table in mind: http://norvig.com/21-days.html#answers
Syscalls are complex beasts, the patches for Meltdown only affect the bit where you transition between userspace and kernel space - this a static cost. Thus, when Avid Media Composer stats a few hundred files on a NAS far, far away from your CPU, the performance cost these patches incur will be negligible.
I would not expect that use case to be affected much. Network latency is too large, relatively speaking, and I don’t think that is “syscall heavy”, even if it does a thousand stat calls.
This patch was released on December 6th, and there haven't been reports of decreased performance from scientific/video editing/etc folks. The worst-case workloads are probably not happening on macOS anyway.
Apple, like intel, is a hardware vendor. They are better off ignoring the performance impairment than recognizing it. Both because of potential litigation costs* and because the performance impact could shift customers away.
*Edit: Also potential reimbursements/compensations and manageing them.
Edit2: What if customers decided to return en mase their new iphone X or macbook they got for christmas?
*Edit: Also potential reimbursements/compensations and manageing them.
Edit2: What if customers decided to return en mase their new iphone X or macbook they got for christmas?
Or, far more likely, and more importantly _actually the case here_, the performance impact for most common macOS workloads is likely to be negligible.
Not everything is a conspiracy theory.
Not everything is a conspiracy theory.
Interesting that this seems to say that A-series processors are vulnerable to Meltdown (or a variant of it).
Could this “check later” speculative approach similar to Intel’s explain Apple’s great performance advantage over other ARM CPUs?
Could this “check later” speculative approach similar to Intel’s explain Apple’s great performance advantage over other ARM CPUs?
> Could this “check later” speculative approach similar to Intel’s explain Apple’s great performance advantage over other ARM CPUs?
No. Speculative execution is not unique to Apple's SoC designs; it's present in other ARM cores as well.
https://developer.arm.com/support/security-update
No. Speculative execution is not unique to Apple's SoC designs; it's present in other ARM cores as well.
https://developer.arm.com/support/security-update
It's mostly assumed the refered performance advantage is directly related to the better and bigger caches in the microprocessor. I'd be surprised that their OOO technique is fundamentally different than other vendors.
> Apple has already released mitigations in iOS 11.2, macOS 10.13.2, and tvOS 11.2 to help defend against Meltdown.
What about macOS 10.12 and earlier versions?
What about macOS 10.12 and earlier versions?
My work machine is 10.12 and patched today.
Sierra and El Capitan is covered too.
https://support.apple.com/en-us/HT208331 - see Kernel entries.
Sierra and El Capitan is covered too.
https://support.apple.com/en-us/HT208331 - see Kernel entries.
10.12 is Sierra. I cannot see any security update in the updates tab of the App Store app, nor in the list of updates that were installed in the last 30 days.
This update shipped to 10.12 on Dec 6 as 10.12.7.
No, there is no macOS 10.12.7 release
https://support.apple.com/downloads/macos
Perhaps you're referring to a release on Dec 6 labeled as "Security Update 2017-002 10.12.6," which does not appear to include the Meltdown patch for Sierra.
https://support.apple.com/downloads/macos
Perhaps you're referring to a release on Dec 6 labeled as "Security Update 2017-002 10.12.6," which does not appear to include the Meltdown patch for Sierra.
I might be super confused about versions, but security update 2017-002 Sierra claims to include the patch according to this page: https://support.apple.com/en-us/HT208331
I'm on 10.12.6 on a Mid 2011 MacBook Air 13": "No Updates Available"
Edit: I see, there is a confusing typo in om2's comment (it should be 10.12.6 not 10.12.7). I am wondering why this update does not show up in my list of installed updates. What a mess.
Edit: I see, there is a confusing typo in om2's comment (it should be 10.12.6 not 10.12.7). I am wondering why this update does not show up in my list of installed updates. What a mess.
It was released as Security Update 2017-002 and 2017-005 for Sierra 10.12.6 and El Capitan 10.11.6 respectively, not as point version updates.
[deleted]
No, 10.12.7 is the right version. It's "available for" 10.12.6, which means that is the version that will be offered the update. I am not sure why it's not showing up for you. Consider contacting Apple support.
Apple patched Meltdown (not Spectre) for Sierra in "Security Update 2017-002" on Dec. 6th 2017. They are not doing a point release; the latest version of Sierra is 10.12.6
If you want to check that you have installed this update, you can use the following command:
If you want to check that you have installed this update, you can use the following command:
$ system_profiler | grep 'Security Update 2017-002'> Since exploiting many of these issues requires a malicious app to be loaded on your Mac or iOS device, we recommend downloading software only from trusted sources such as the App Store
Haven’t there been JavaScript POCs for Meltdown? That’s already patched and AFAIK there’s nothing for Spectre yet, but this is still a little disingenuous.
Haven’t there been JavaScript POCs for Meltdown? That’s already patched and AFAIK there’s nothing for Spectre yet, but this is still a little disingenuous.
Aren’t the browser patches already shipping? The JS risk should be significantly lower with days.
I wonder what's going to happen to old Android devices that are no longer receiving security updates
If there are no global, industry-wide incentives to fix this particular, once-in-twenty-years issue, they become the world's largest botnet.
Apple and Google should want old devices to be patched, to avoid teaching consumers that their devices cannot be trusted.
Apple and Google should want old devices to be patched, to avoid teaching consumers that their devices cannot be trusted.
Google will on their pixel phones. But the other OEMs tend to not be good about updates. A big plus for the Pixel in the Android world.
There's no remote exploit though, right? So the only way an attacker could turn this into a botnet would be to somehow get Android apps to run attacker controlled code or exploit existing code that fits the pattern described in the attacks (seems not to exist in practice). These aren't super high bars, but they do make the exploit significantly harder.
Couldn't old Android web browsers be targeted?
It seems like it (didn't see that there was a JS version of the exploit until after I posted), although they can only read from the address space of the process the JS code is running in. I think tabs get individual processes (in Chrome at least), not sure about Firefox or other browsers, so I'm not sure how bad this is in practice.
Nothing.
Until Google takes the stand and actually forces OEMs to update, nothing will ever change.
Not for existing devices, nor for Treble certified ones.
Updates are only for rich people able to pay 500€+ for flagship devices every three years.
Until Google takes the stand and actually forces OEMs to update, nothing will ever change.
Not for existing devices, nor for Treble certified ones.
Updates are only for rich people able to pay 500€+ for flagship devices every three years.
Google will for the Pixel and if the other OEMs drag their feet more will get the Pixel. That is on the OEMs.
Not they won't not everyone is swimming in money to buy a Pixel every three years.
Additionally not all countries are deemed worthy of being able to buy Pixel.
Additionally not all countries are deemed worthy of being able to buy Pixel.
Treble is counterproductive to this sort of problem anyway. But abstracting the OS to a layer sat above a quasi-HAL as it does, users will get OS updates with features but without updates to the underlying hardware interface blobs. The incentive for OEMs to update drivers for security goes down radically, not up, because the users crying out for OS feature x get it without having to update anything below the abstraction layer.
Ultimately the problem with Android driver security is that Qualcomm has no interest in it, and won't until some form of legislation from a large territory such as the US, EU or China forces their hand on it.
Ultimately the problem with Android driver security is that Qualcomm has no interest in it, and won't until some form of legislation from a large territory such as the US, EU or China forces their hand on it.
No they won't, because Google keeps saying that even with Treble, OEMs are the ones responsible to push any kind of update not Google.
So unless Google changes their mind, users will get the same amount of updates as they are getting now on non-Treble devices.
So unless Google changes their mind, users will get the same amount of updates as they are getting now on non-Treble devices.
Updates are only for rich people able to pay 500€+ for flagship devices every three years.
And only when you buy it on day one:
Pixel phones get security updates for at least 3 years from when the device first became available on the Google Store, or at least 18 months from when the Google Store last sold the device, whichever is longer. After that, we can't guarantee more updates.
Source:
https://support.google.com/pixelphone/answer/4457705?hl=en
And only when you buy it on day one:
Pixel phones get security updates for at least 3 years from when the device first became available on the Google Store, or at least 18 months from when the Google Store last sold the device, whichever is longer. After that, we can't guarantee more updates.
Source:
https://support.google.com/pixelphone/answer/4457705?hl=en
Damn it’s 2000 all over again. Cybermagedon is the most annoying thing. It always appears when I am in low supply of pop corn.
Does Geekbench test for TLB flushes at syscalls or whatever other kind of "mitigation" they introduced in 10.13.2 ? Where can we see true benchmarks of performance comparison between previous and current version in regards to this bug ? Isn't Apple being really nasty by exploiting the lack of knowledge of the general public ?
I am no expert in any way but would like to know how did they "mitigated" this without a serious performance hit.
I am no expert in any way but would like to know how did they "mitigated" this without a serious performance hit.
You should try defining this mystical true benchmark that you seek.
Apple decided that heavy userspace execution and web performance are representative of common workloads. You are welcome to argue for a different kind of workload. As it stands now, at best you're implying that it's common for users to execute syscalls in a loop.
Apple decided that heavy userspace execution and web performance are representative of common workloads. You are welcome to argue for a different kind of workload. As it stands now, at best you're implying that it's common for users to execute syscalls in a loop.
Can you tell with any degree of precision what kind of benchmark the "GeekBench" is and does ? What guarantees do you have that it is testing "real world common workloads" ?
Do you think common users execute guassian blurs in a loop and ray tracers before perfoming rigid body physics in their "common workloads" ? As you said, I know I am welcome to argue for a different kind of workload, specially when I am being taken for a fool.
Do you think common users execute guassian blurs in a loop and ray tracers before perfoming rigid body physics in their "common workloads" ? As you said, I know I am welcome to argue for a different kind of workload, specially when I am being taken for a fool.
I'm not too familiar with GeekBench, but I'm assuming it's userspace code. Whether it traces rays or does something else isn't that important, because the slowdown is with syscalls.
As for what common users execute, based on my observations over the years it's mostly web browsing. However my personal vision of common workloads is a distraction. I have made no claims to know common workloads. I merely stated that Apple has chosen a particular set to be representative.
As for what common users execute, based on my observations over the years it's mostly web browsing. However my personal vision of common workloads is a distraction. I have made no claims to know common workloads. I merely stated that Apple has chosen a particular set to be representative.
More like Phoronix doesn’t do any analysis of what they’re benchmarking and the general public quoting them can’t do that for them.
Besides, syscalls have historically been slow on OS X; back when the kernel was 32-bit the kernel and user space had completely separate address spaces (unlike windows and default Linux) and I’ll bet even most power users never realized.
Besides, syscalls have historically been slow on OS X; back when the kernel was 32-bit the kernel and user space had completely separate address spaces (unlike windows and default Linux) and I’ll bet even most power users never realized.
What about macOS 10.12? I haven't seen enough stability across applications with High Sierra to make the upgrade for work machines. I guess we'll have to just wait it out to see what they actually release.
It's gotten the same patches as 10.13. The original security advisory did not mention it, but it's been revised now: https://support.apple.com/en-us/HT208331
Kernel
Available for: macOS High Sierra 10.13.1, macOS Sierra 10.12.6, OS X El Capitan 10.11.6
Impact: An application may be able to read kernel memory
Description: Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache.
CVE-2017-5754: Jann Horn of Google Project Zero, Werner Haas and Thomas Prescher of Cyberus Technology GmbH, and Daniel Gruss, Moritz Lipp, Stefan Mangard and Michael Schwarz from Graz University of Technology[deleted]
> Intel said its chips, which power Macs and devices from other manufacturers, contain the flaw as well as processors based on ARM Holdings architecture, which is used in iOS devices and Android smartphones.
Has it been proven that Meltdown can affect ARM processors, or is this Intel speculation?
Has it been proven that Meltdown can affect ARM processors, or is this Intel speculation?
Google tested a Proof-of-Concept exploit against an ARM Cortex A57.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
disclaimer: I work at Google, but not on Project Zero.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
disclaimer: I work at Google, but not on Project Zero.
According to ARM yes, but only on a few architectures: https://developer.arm.com/support/security-update (Meltdown is CVE-2017-5754 and is responsible for Variant 3 and Variant 3a). See also https://github.com/marcan/speculation-bugs/blob/master/READM... which tries to summarize every known attack/platform/mitigation.
Cache timing attacks are a pretty general technique, and just depends on the combination of speculative execution + not flushing the cache upon misprediction rollback (which would be very expensive).
It would be a huge surprise if ARM were somehow immune.
It would be a huge surprise if ARM were somehow immune.
It can impact them, just not to the same extreme. I believe ARM is only impacted when data is user space to user space.
Meltdown affects Intel chips, Spectre affects Intel, AMD, and ARM chips.
Meltdown also affects some ARM chips according to ARM itself: https://developer.arm.com/support/security-update
Spectre likely affects any chip with speculative execution, regardless of vendor, even things like Power8. So that's fun.
So nothing required on hardware side? I was under the impression that OEMs need to send out BIOS/UEFI Firmware updates or at least CPU Microcode updates but doesn't look like Apple is planning to do so.
MacOS update packages include any relevant firmware updates at the same time.
At least in the linux kernel, it was patched by essentially throwing off the branch predictor following every syscall, which didn't require any hardware, bios, or microcode patches.
Microcode updates will come down the pipe to users as OS updates as Intel uses these channels.
Yeah I think if a UEFI update comes down it might bring the mitigated uCode with it. Just got to boot into USB macOS installation - don't think Boot Camp users get those updates.
They say the watches aren’t effected.
Is it possible that they don’t do speculative execution?
Is it possible that they don’t do speculative execution?
I think it's only Meltdown that the watch isn't affected by.
It sounds like it is potentially affected by Spectre, especially since they say they will be continuing to develop mitigations for WatchOS.
The surprising thing to me is that they patched iOS to mitigate Meltdown. Before now, I thought it was only Intel chips that were affected by Meltdown, but I guess Apple's own A-series processors are affected too.
It sounds like it is potentially affected by Spectre, especially since they say they will be continuing to develop mitigations for WatchOS.
The surprising thing to me is that they patched iOS to mitigate Meltdown. Before now, I thought it was only Intel chips that were affected by Meltdown, but I guess Apple's own A-series processors are affected too.
Yes some ARM Cortex A-series are affected by a variant of Meltdown. https://developer.arm.com/support/security-update
Highly unlikely.
> Apple Watch is not affected by Meltdown.
i.e. by the lemma of overly specific dementi it follows that Apple Watch is affected by Spectre.
> Apple Watch is not affected by Meltdown.
i.e. by the lemma of overly specific dementi it follows that Apple Watch is affected by Spectre.
That's probably it. The original S1 was based on the A7 which was in-order. But I can't find information on the S2 onward.
I don’t have any citations but I believe the S1 is actually based on the A4 of all things. It was 32 bit.
I wonder if Apple can retro-actively add the retpoline trick to the apps submitted in bitcode.
If so, then I expect Apple to make bitcode mandatory.
What about iOS10 users who need to run 32-bit apps?
How long has Apple warned users that 32 bit software wasn't going to be supported?
For context, the only phones that are not being supported by the latest patch are iPhones introduced before 2013.
For context, the only phones that are not being supported by the latest patch are iPhones introduced before 2013.
If the app vendor has gone out of business and there is substantial data in the 32-bit app, there may be no upgrade alternative.
And can you name a few real world examples?
Several are named here: https://tidbits.com/article/17342
I haven't dug into the list too carefully but would you really use a productivity app from a small company that doesn't have anyway to export the data?
Even my third party podcast client supports exporting to OPML.
Even my third party podcast client supports exporting to OPML.
Are secrets within the secure enclave vulnerable? e.g. Bitcoin wallet keys
[deleted]
So, older versions not fixed? Who is most likely to be running older version? Corporations? Ah, they probably don't care.
Sierra and El Capitan are covered too.
Do you have a source for that because:
a) The article above doesn't mention it (specifically says 10.13), and
b) There are no updates available for my mac.
a) The article above doesn't mention it (specifically says 10.13), and
b) There are no updates available for my mac.
I'm running an older version because I prefer to let other folks grind the rough edges off of the APFS filesystem before taking the plunge myself.
> but there are no known exploits impacting customers at this time
known by whom? Apple? Then say "we do not know of any exploits". Is the answer different for the NSA? Who the f knows?
known by whom? Apple? Then say "we do not know of any exploits". Is the answer different for the NSA? Who the f knows?