Intel Memory Access Design Flaw Partially Addressed by Apple in macOS 10.13.2 [Unconfirmed] (macrumors.com) 49
An anonymous reader shares a report: A serious design flaw and security vulnerability discovered in Intel CPUs has reportedly already been partially addressed by Apple in the recent macOS 10.13.2 update, which was released to the public on December 6. According to developer Alex Ionescu, Apple introduced a fix in macOS 10.13.2, with additional tweaks set to be introduced in macOS 10.13.3, currently in beta testing. AppleInsider also says that it has heard from "multiple sources within Apple" that updates made in macOS 10.13.2 have mitigated "most" security concerns associated with the KPTI vulnerability. A Bloomberg reporter pointed out that Apple has not officially commented on the story.
Fingers crossed for Sierra (Score:1)
Re: (Score:2)
Re: (Score:2)
Was initially fixed in 10.12.3, 10.13.2 is an update to the existing fix.
Where are you seeing this? All I see are reports that 10.12 has NOT been fixed [twitter.com].
Re: (Score:2)
https://security.archlinux.org... [archlinux.org]
Re: (Score:2)
But 4.14.11 doesn't include the fix that disables slowing down AMD processors. That one has been committed for 4.15, but there should also be a 4.14.12 to fix it there too.
Re: (Score:2)
I'd get my passwords tattooed on my forehead before I try using High Sierra again.
I hope on the inside...
Re: (Score:2)
Given they consistently post security fixes for the three most recent versions of the OS, I would expect this was included in the December 6 security updates for El Capitan and Sierra as well.
It's not like Apple actually makes any noise regarding the updates for its older OSes... they just show up in the App Store, and you have to go look at the relevant knowledge base article to learn anything. And given that this purported fix is "someone said this", it's not surprising that 10.11 and 10.12 weren't mentio
Re: (Score:2)
Following up...
Apple updated the page describing last month's security patches [apple.com] to explicitly state the same kernel fixes were put in place for High Sierra, Sierra, and El Capitan.
Re: (Score:2)
...and they updated the document AGAIN today, and removed the references to Sierra and El Capitan. So, at the moment, those are apparently not patched after all.
Re: (Score:2)
They will wait until after the Christmas Shopping Season to tell you about the $29 option.
"Your phone is SLOW. You should buy a NEW phone."
How long is THIS (incorrect) meme going to rattle-around Slashdot?
Re: Throttle CPU (Score:1)
Re: (Score:2)
Honest question: What is incorrect about this? Apple has admitted that they slow down phones with bad batteries (which would include the iPhone 6s that *shipped* with bad batteries.) When asked about a slow phone, Apple Store employees do suggest buying a new one.
But, again honestly:
1. Did Apple KNOW that the 6s "Shipped with bad batteries", and if so, when? EVERYONE has supplier-issues once in awhile (See, Samsung Note 7). It's how you RESPOND to those issues that is important.
2. Is the Apple Store employees' suggestion a Company Policy; or just some overly gung-ho salespeople who didn't have any special knowledge of the battery-saving software, either? I would bet nearly my last dollar that Apple didn't TELL their store employees to "suggest buying a new one."
Re: (Score:1)
Apple told the employee: "Your numbers aren't looking so good. You better sell more or we'll have to let you go."
There was no 'nudge nudge, wink wink' either. There didn't need to be one.
Re: (Score:2)
Apple told the employee: "Your numbers aren't looking so good. You better sell more or we'll have to let you go."
There was no 'nudge nudge, wink wink' either. There didn't need to be one.
Prove it.
Re: (Score:1)
Mister Literal presents his fuckhead defense of Apple.
No, not interested in proving anything to you. You're just somebody here to toy with, because you're a religious cult member. Nerds like to make fun of people like that.
Carry on, moonie.
Re: (Score:2)
Mister Literal presents his fuckhead defense of Apple.
No, not interested in proving anything to you. You're just somebody here to toy with, because you're a religious cult member. Nerds like to make fun of people like that.
Carry on, moonie.
Well alrighty, then!
I guess we're done here...
Re:Throttle CPU (Score:5, Informative)
Funny thing is that this bug is almost an example of Intel throttling old hardware. The KPTI fix is apparently less of a performance hit if you have a new Intel CPU with PCIDs
https://www.theregister.co.uk/... [theregister.co.uk]
Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features - such as PCID - to reduce the performance hit. Your mileage may vary.
PCID - Process Context ID - means you can tag the TLB entries with a 11 bit process ID.
http://forum.osdev.org/viewtop... [osdev.org]
Also, the Intel manual says bit 0-11 of CR3 is used as the PCID. Does it somehow related to the usual process id user mode code see? If yes, does it mean it imposes a limit on the # of user processes (4096) allowed ?
Which means you don't need to flush the whole TLB - you just invalidate the ones which belong to a process you're switching away from
http://linuxeco.com/?p=488 [linuxeco.com]
A PCID is a 12-bit identifier, and may be thought of as a "Process-ID" for TLBs. If CR4.PCIDE = 0 (but 17 of CR4), the current PCID is always 000H; otherwise, the current PCID is the value of bits 11:0 of CR3. Non-zero PCIDs are enabled by setting the PCIDE flag (bit 17 of CR4).
When a logical processor creates entries in the TLBs (Section 4.10.2 of the x86 prog reference manual) and paging structure caches (Section 4.10.3), it associates those entries with the current PCID (Oh ... such a loose association of PCID with PID). Note that this means that where the PGD is located is somehow being interpreted in the PID "process context". When using entries in the TLBs and paging-structure caches to translate a linear address, a logical processor uses only those entries associated with the current PCID, and hence flushes of the TLB are avoided.
Presumably you could have on PCID value for the kernel and the other 4095 for tasks and not need to go a TLB flush when switching until the PCID value wrapped.
Of course that means you need a sufficiently recent Intel CPU.
https://software.intel.com/sit... [intel.com]
FMA, AVX2, BMI1, BMI2, INVPCID, LZCNT, TSX - Haswell and later
I.e. you need a Haswell 4xxx processor or later
https://en.wikipedia.org/wiki/... [wikipedia.org]
At least for the Linux KPTI fix it seems like it does support PCID
https://lwn.net/Articles/74060... [lwn.net]
- Integrated all fixes and Peters rewrite of the PCID/TLB flush code.
So does the macOS fix
https://www.macrumors.com/2018... [macrumors.com]
Ionescu also says that performance drop on a system with PCID (Process-Context Identifiers), available on most modern Macs, is "minimal," so most users may not see an impact on day-to-day Mac usage.
Of course if you have an 2012 Macbook Pro you've got an i5-3210M so you don't have PCID so you'll either have an insecure machine or a performance hit.
Interesting thing is if there was a class action lawsuit, I wonder if you could get Intel to give you a new CPU with PCID to minimise the impact of the bug fix.
Thankfully PCID has around for a while... (Score:4, Informative)
I was thinking only the very most recent processors had PCID, but looking at my 2013 MacBook Pro, even that has PCID (Intel Core I7). So at least from the i7 on it seems like systems may not be too affected, probably most developers have at least an i7 in current systems.
KPTI isn't the "vulnerability" (Score:1)
So this article is pretty wrong. First of all, KPTI -- kernel page table isolation -- isn't a vulnerability, it's a security framework that prevents meltdown (and more importantly a bunch of other potential attacks) from being effective.
Oh no. (Score:1)
Re:Oh no. (Score:4, Insightful)
If your AI can't figure out it's way around silly processor errors you've got a problem. Deep learning likes noise. You add extra, on purpose.
Regular algorithms are fragile and usually don't work if the numbers don't add up. But be fair: Intel has had two real bugs that I remember, in the last... forty years? Outside of those two, I doubt anyone has even contemplated the need to patch their processor. Not many projects in the computer business can say that.
Re: (Score:1)
"Outside of those two" - Which rock are you hiding under? You should look at the processor errata sheets. Then you'll wonder how your computer ever works right. Many computer crashes and hangups are actually due to processor bugs.
So (Score:2)
Doubly impacted (Score:2)
Although your post is a throwaway joke, it actually hits on a real issue for Android. Not only do Android devices generally have a harder time getting patches, Android itself is way more open to applications having background tasks running... which is important for actually taking advantage of a Spectre exploit. On iOS apps running background tasks are much more limited in duration and ability, and so have much less of a chance to have a meaningful attack on other apps running simultaneously.
Re: (Score:1)
Re: (Score:3)
It impacts everything, yes, but key to Spectre doing anything useful is that you have two applications running at once. So on a desktop or on servers Spectre is still a big deal, but on mobile devices it's more limited since mostly you are running one application at a time and other applications are offloaded. The more that is true the safer you are, and in IOS applications are generally offloaded sooner and not running processes in the background for an attacker to collect data from.
Re: (Score:1)
Re: (Score:1)
Re: Doubly impacted (Score:2)
"most" (Score:2)
no thanks (sarcsasm) (Score:4, Funny)
so... (Score:2)
Official Statement (Score:2)
Apple have now commented on the issue.
https://support.apple.com/en-u... [apple.com]