Slashdot Mirror
Intel Memory Access Design Flaw Partially Addressed by Apple in macOS 10.13.2 [Unconfirmed] (macrumors.com)
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.
I hope they will fix this in 10.12.x too. I'd get my passwords tattooed on my forehead before I try using High Sierra again.
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.
And Intel can't seem to get stuff right, P90 bug anyone. What happens when they go AI or deep learning and have similar issues? No one is perfect but I am certainly a bit concerned.
Android shitphones will have to be tossed in the garbage because we all know those pieces of waste will never be patched! (Yes, Spectre affects ARM)
Like we've already addressed most vulnerabilities ever discovered? (It's the new, unaddressed ones that bite you.)
This is outrageous that Apple is rolling out some software update to "help" our processors function better without asking us! I demand to be asked whether I want this software fix to be implemented, because it makes my processor work slower! Apple sucks and don't get me started on batteries.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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."
God may exist. Or he may not. Or she may have gotten a sex change. If she exists.
Should we expect a corresponding performance hit?
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/...
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...
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
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...
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/...
At least for the Linux KPTI fix it seems like it does support PCID
https://lwn.net/Articles/74060...
- Integrated all fixes and Peters rewrite of the PCID/TLB flush code.
So does the macOS fix
https://www.macrumors.com/2018...
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.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
SOL
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Love the wording:
This: "addresses design flaw" (but it's only rumoured, how is there no official patch note?!?)
Corresponding windows: "patches bug" (again, Windows is "buggy" lol)
Nice
So your system is partially secure?
Is your wife partially pregnant?
Apple users are terminally stupid egomaniacs.
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?
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.
How's life in the hypocrite lane?
Apple have now commented on the issue.
https://support.apple.com/en-u...
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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."
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.
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.
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.
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...