Sorry but I think you didn't read my reply - TSMC (I said) is dealing with Chip fabrication - The Bionic uses parts from ARM and other companies which TSMC lay onto the die at Apples request/direction. Didn't say any different to your statement. The A11 features a pure ARM chip - just not a commercially available one to other parties.
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 Claims Security Flaw Also Impacts Non-Intel Chips, Exploits Can't Corrupt, Modify or Delete Data [Updated]
- Thread starter MacRumors
- Start date
- Sort by reaction score
Sorry but I think you didn't read my reply - TSMC (I said) is dealing with Chip fabrication - The Bionic uses parts from ARM and other companies which TSMC lay onto the die at Apples request/direction. Didn't say any different to your statement. The A11 features a pure ARM chip - just not a commercially available one to other parties.
There is a memory read that takes place! In fact, in one of the examples, there's the read of protected space, a masking of the result, a shift left, and another (user space) read using the masked&shifted value as an array index. All of this is normally hidden under the veil of speculative execution.
The cache timing is just a way of getting the gleaned information out from behind the veil.
This is like a soundproof room where you've placed a trained parrot near a window. The parrot flaps its wings every time it hears the word "nuclear."
...
Another example of why this is a bug: Imagine a totally non-malicious program. This program has a linked list. The "next" pointer of the last entry hasn't been initialized. The random bytes there turn out to point to a sensitive i/o address. The program detects the last list entry via other means - maybe a Boolean flag, or it knows the pointer to the last entry. The program is searching through the list. This trains the branch predictor to expect repeated iterations. The program reaches the end of the search and breaks out of the loop. However, speculatively executed code goes one step further, performing a read of the sensitive address.
CPU does not perform speculative reads of memory mapped I/O addresses. I do not know the details how this is done exactly on x86, but I assume that the page table contains a flag that disables caching. So you don't have to worry about this case.
As to the other kind of speculative reads, they have no effect on the state of the executed code and you cannot in any way access data that has been speculatively loaded and then discarded. There is a side effect (timing differences), sure, and its what is exploited here, but in itself, the read is not visible to your code.
I hope that you are not suggesting to disable speculative memory loads altogether. That is a sure way of killing performance
You are still wrong. There are no “parts from arm” on the die. Arm provides an architectural specification - essentially the instruction set. While many other companies also receive RTL and/or netlists and even layout from ARM, Apple does not. Apple designs all the ”parts” themselves. Apple designs every circuit, and decides where every transistor goes on the chip. They decide how many pipeline stages there will be, how many pipelines there will be, how many reservation stations, how big the caches will be, how big the internal buses will be, how branch prediction will work, etc. Within a pipeline they do all the logic design, deciding how the integer adder will be architected (e.g. Ling vs. others, etc), they decide on the logic design, they decide what circuits will implement that logic, and then they draw all the transistors and wires themselves. They could have put on circuits to never load anything into the cache if there’s even a remote possibility that an instruction would access privileged memory, and it would still meet the ARM architectural specification (and would be immune from these attacks). If Apple wanted to, they could have designed the cpu to issue on-order (which they did do for Apple Watch) and, again, it meets the arm architecture specification.
Wonder how long these chip flaws would have kept going on before being exposed!! These tech companies must have already known about these issues, only reason they came up with some BS story about revelling it a week later, is because they got caught!! Instead of weakening security on all these devices and software, from government agencies influences, why don’t all of you step up to the plate to build a secure products and software!! Yes I know your all profit oriented, that’s why secure products and software will always fail, after all it’s not profitable, like selling information. If you watch all these tech company’s their bottom line is profit, when their pocket books take a hit, that’s when security takes on an importance! If you care about your customers build security and safe products, stop the lip service, actually do what you say instead of thinking of other ways to under mind your customers behind closed doors or doing back room deals with government agencies!!!!
Last edited:
I don’t buy it. I designed CPUs. Several of them seem like they would be subject to Spectre attacks. I didn’t know about the problem because I wasn’t thinking about side channel attacks and neither was anyone else. You can steal data by monitoring power usage and fan speed, too. There have been real attacks published. But it would never occur to me to try and do anything to protect against those attacks. These new ones are more dangerous since they are easier to implement, but this isn’t the sort of thing chip designers have thought about. We worried about direct attacks - making sure that data in one domain can’t be read in another domain using the normal instruction mechanisms. But it never occurred to us to worry that the results of one instruction would cause a future instruction to sometimes run faster, and thus reveal information if tested many many times.