Well, crap... Only ever been on 10.13.2 on my MacBook. Now I don't know whether I can or should be upset...
I'm a number of versions back on my iMac and will prolly stay that way...
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Intel Chips Have Memory Access Design Flaw and Fix Could Lead to Performance Drop
- Thread starter MacRumors
- Start date
- Sort by reaction score
Well, crap... Only ever been on 10.13.2 on my MacBook. Now I don't know whether I can or should be upset...
I'm a number of versions back on my iMac and will prolly stay that way...
Since you obviously have absolutely no idea what you're talking about, let me explain - this is HEAVIER load than 'real world' examples.
LOL
You have to admit, some folks response makes it clear they don't understand the issues, causes, fault, etc.
No kidding. I was planning to order a fully loaded IMac Pro today. Then I saw the news and my purchase is indefinitely postponed. Computer makers are not going to like the hit to sales at least in the new term until this gets sorted and the full impacts understood on performance and security.
I and other Mac users are grateful that you don't make the decisions for Apple.
Wow. I had a 486DXll66 once. It was the King in it's time. I was stoked to run Falcon 3.0 and it's polygon terrain.
It was a special chip..no doubt, one reason I cannot forget owning it
Actually Postgres, the database people say around 20%:
https://www.postgresql.org/message-id/20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
Fine. How do they deal with the fact that now their no. 1 customer application software product is WINDOWS. In the times you referred to, they had not supported WINDOWS. Now that they have, and their customers depend on it, how are they going to go in a way that would remove that ability. The value of the Mac today is that it runs all of the software-OS X AND windows AND Linux. To go to arm would destroy that. Yes, emulation- NO to emulation. Been there done that.
I think I just read somewhere that AMD and ARM are indeed affected. Looks like it is most likely a method which is common use in CPU architecture. What a shame.
I believe that we will discover that Mac's will be some of the least affected systems. Not only does it appear that Apple was the First major OS developer to patch their OS, but the types of workloads that Mac users run seems to be among the least impacted. The people who will be screaming are those running Server workloads (databases-virtualization,etc.), they are going to be killed.
[doublepost=1515032401][/doublepost]
[doublepost=1515032401][/doublepost]
This situation keeps changing for obvious reasons. At the moment it looks as if Intel is most affected, ARM is very affected and AMD is somewhat affected. ARM's situation could be worse in that there is no possibility of a fix if I understand it correctly. CPU's have to be redesigned and replaced.
AMD is affected by a much less severe form of a problem in the same family. Essentially you can tell if a particular value was in the kernel by timing how long it takes to fetch a value (so you can see if it was in the cache vs. RAM. If it was in the cache, it's because speculative execution put it there). It's a side-channel attack which is pretty hard to do much with. ARM seems to be subject to the same attack as Intel, but that might only apply to those using ARM's own designs (which Apple does not).
[doublepost=1515032768][/doublepost]
Windows is absolutely not apple's "no 1. customer application software product." The vast majority of Apple Mac customers do not run windows on Mac.
I would have thought microcode update to processor would fix this, since "all processors are affected" are they not...? Why bother fixing it externally in the OS, if the processor controls everything..
All your doing is releasing the flawed instruction, but "soft-patch"ing it afterwards.
All your doing is releasing the flawed instruction, but "soft-patch"ing it afterwards.
Oh I get it, Intel didn’t do anything wrong, so why hold them responsible?
can't update it in microcode since the flaw involves the fundamental operation of the instruction scheduler.
Correct! Especially when the hardware already has to handle the case where the address was unmapped and couldn't be read under any conditions.
If a process isn't allowed access to memory, than we can say it shouldn't assume any particular contents. What if the errant read is treated as a pointer and the subsequent location is also read - and that address is a location that causes the machine to crash?
Is this fixed in Sierra?
edit; looks like new security fix is here, dont know what it does
Last edited:
The point is you always need a backup plan.so you are telling me they knew before this?
[doublepost=1515042971][/doublepost]
Oh it will take time until they replace the high-end processors in Mac Pros and iMac Pros, that's for sure.
But right now, if you take the processor found in an iPad Pro 1st gen when it was released, the A9X was faster than 80% of the laptops shipped the year before. We don't know yet what the A11X performance will be in the iPad Pro 3rd gen, but the expectations are enormous, considering the iPhone X is already faster than too many laptops with just an A11.
[doublepost=1515043115][/doublepost]
That would be true for laptops, not desktops.
And about the battery thing, I'll still wait and see what happens. I don't know why the iPhones 1, 3G, 3GS, 4, 4S and 5 were all on ARM and did not require this shady practice, but modern phones do.
Last edited:
Because Intel isn’t the company you’re buying hardware from. Apple is.
When the Volkswagen scandal happened, you didn’t sue Bosch, who made the software. You sued VW, who sold you the car.
Anything conforming to the x86-64 spec that Intel used would be affected. Core and newer would be affected, so Core2, Core2Duo, possibly as far back as Pentium 4F, all the way up to Cannonlake.
The saving grace here is that it doesn't have anything to do with the x86-64 spec, otherwise every PC-grade CPU would be affected.
EDIT: Actually, I take that back. It isn't just these CPUs that are affected. There is a similar bug relative to the x64-64 spec that affects all 64bit AMD processors and 64bit ARM as well. So there is a much bigger issue here than just Intel.
The question now becomes that if Apple already addressed this in 10.13.2, will that patch be backported. This is really nasty.
BL.
Last edited:
On the contrary here. You would go after Intel for selling defective hardware. You, the consumer would go through Apple, who would then in turn go to Intel for supplying defective hardware. Your course of action would be to go through Apple to get the hardware fixed, but it in turn would be at Intel's expense.
If I built my own computer (which I do for a living), my grievance would directly be with Intel. For the servers I maintain, I would go through Dell (the one who we bought the hardware from), but Dell would then charge Intel for the entire incident.
In this case, you wouldn't sue Apple, because Apple isn't negligent in this case. You'd go after Intel for supplying your hardware company buggy hardware.
BL.
I bought an Intel CPU from a computer shop, I should sue myself for my decision to buy it? The shop for selling it to me? The distributor the shop bought it from? Are any of these entities responsible for the defective CPU? Or would that be Intel?
In law, those who do wrong are the ones held responsible. Intel’s lawyers can’t just tell the judge, “well, sure, our client designed and made defective CPUs, but Apple bought them so it’s actually their fault.” Apple played no role in Intel’s designing, manufacturing and selling of defective chips to millions of Intel’s customers (of which Apple is only one).
You present a flawed analogy. VW was sued because they were the responsible party. It was they who decided to cheat on the emissions tests, not Bosch. VW pleaded guilty to fraud and paid $20 billion in fines and penalties because VW executives made the decision to criminally defraud their customers.
In fact, Bosch was also complicit, as VW didn’t know how to program the software to recognize emissions testing and (only) activate the emissions controls properly when this compliance testing was detected. Bosch knew, or should have known, why VW asked them to make the software operate as it did.
So your analogy falls apart, since Bosch did have a role in VW’s deliberate and criminal fraud, and was therefore held accountable. Bosch paid hundreds of millions of dollars in the US in a legal settlement for writing that cheat software, albeit at VW’s request.