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.
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.
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.
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.
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
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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?
> 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.
> 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.
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"
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
> 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?
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.
> 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?
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.
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.
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
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.
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.
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.
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.
Hmm, so Apple confirms that meltdown happens on ARM as well, interesting. Likely their Axx chips are way faster than competition, allowing the timing window in which to execute the attack, as Google suggested.
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.
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.
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.
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.
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.
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:
110 comments
[ 3.7 ms ] story [ 203 ms ] threadIs it possible that they don’t do speculative execution?
> 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.
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.
What about macOS 10.12 and earlier versions?
Sierra and El Capitan is covered too.
https://support.apple.com/en-us/HT208331 - see Kernel entries.
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.
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.
a) The article above doesn't mention it (specifically says 10.13), and
b) There are no updates available for my mac.
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
known by whom? Apple? Then say "we do not know of any exploits". Is the answer different for the NSA? Who the f knows?
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.
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.
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 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
*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?
Not everything is a conspiracy theory.
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.
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.
[1] http://gs.statcounter.com/macos-version-market-share/desktop...
Clear as mud.
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?
For context, the only phones that are not being supported by the latest patch are iPhones introduced before 2013.
Even my third party podcast client supports exporting to OPML.
Has it been proven that Meltdown can affect ARM processors, or is this Intel speculation?
Did Google name it Spectre after the the James Bond movie?
And I thought AMD put out a release saying they are not affected.
It would be a huge surprise if ARM were somehow immune.
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
disclaimer: I work at Google, but not on Project Zero.
Apple and Google should want old devices to be patched, to avoid teaching consumers that their devices cannot be trusted.
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.
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.
So unless Google changes their mind, users will get the same amount of updates as they are getting now on non-Treble devices.
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
Additionally not all countries are deemed worthy of being able to buy Pixel.
I am no expert in any way but would like to know how did they "mitigated" this without a serious performance hit.
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.
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.
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.
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.
If you want to check that you have installed this update, you can use the following command: