News New chip flaw hits Apple Silicon and steals cryptographic keys from system cache — 'GoFetch' vulnerability attacks Apple M1, M2, M3 processors, can...

D

Deleted member 2731765

Guest
I wouldn't call this an entirely new threat on Apple DMPs though.

Remember AUGURY ? However, there was this "false notion" that this augury didn't pose much of a threat, that it could only leak data pointers and likely only in the 'sandbox threat' model, (and a fault that Augury was unable to mix data and addresses when constant-time practices were used).

Some researchers thought it only prefetched when the content was a valid virtual address.



"The only exception is Apple's M3 silicon which purportedly features a special "switch" that developers can turn on to disable the chip's data memory-dependent prefetcher."

What switch ? They are talking about a special bit which can be flipped to disable DMP. DIT bit set on M3 effectively disables the DMP. This is not the case for the m1 and m2.

Some suggest using a lib like 'libsodium' to simply set the disable bit prior to cryptographic operations that are sensitive on M3, but this sounds impractical.

https://developer.arm.com/documenta...Arch64-Registers/DIT--Data-Independent-Timing

"The interesting tidbit is that Intel's Raptor Lake CPU architecture (which includes both 13th and 14th Gen CPUs) doesn't have this vulnerability despite sharing the same prefetcher as Apple's M series chips. We don't know why this is the case,"
Because the DMP found in Intel’s Raptor Lake processors doesn’t leak the same sorts of cryptographic secrets.

Apart from that, this DOIT bit can also effectively turn off the DMP. Raptor Lake processors can disable DMP by using the Data Operand Independent Timing bit.

https://www.intel.com/content/www/u...-operand-independent-timing-isa-guidance.html
 
Last edited by a moderator:

rluker5

Distinguished
Jun 23, 2014
911
594
19,760
Large caches where the same data exists in both cache and ram are inherently vulnerable to side channel attacks. There will be more.

A shame since speeding up access to data is so helpful in speeding up the total time to process. I hope Apple finds a fix that doesn't hurt performance too much.
 
I wish I had seen this earlier yesterday. Last night I purchased an iPhone 15 Max Plus for over $2,000 and ordered an iPad Pro Max with cellular for an additional $2,500. Last night I canceled my iPad order and later this morning I'm returning my iPhone. I deal with seven figure plus financial accounts, and I cannot take the risk. It's that simple. Perhaps their next CPUs will fix the problem. There's just too much on the line for me.
 
Mar 23, 2024
2
1
15
I wish I had seen this earlier yesterday. Last night I purchased an iPhone 15 Max Plus for over $2,000 and ordered an iPad Pro Max with cellular for an additional $2,500. Last night I canceled my iPad order and later this morning I'm returning my iPhone. I deal with seven figure plus financial accounts, and I cannot take the risk. It's that simple. Perhaps their next CPUs will fix the problem. There's just too much on the line for me.
I fully agree, unfortunately this is a complete disaster and people should really think twice when purchasing anything using these CPUs. I would also have returned those devices the next day.
 
  • Like
Reactions: Amdlova

bit_user

Titan
Ambassador
Last night I canceled my iPad order and later this morning I'm returning my iPhone. I deal with seven figure plus financial accounts, and I cannot take the risk. It's that simple. Perhaps their next CPUs will fix the problem. There's just too much on the line for me.
So, you're alternative is just to use older devices that don't have the vulnerability? Because it doesn't sound like you're about to leave the Apple ecosystem.

I think there are software mitigations Apple can do, but they're not great. They would be things like trying to detect web apps or store apps which contain code that seems like it's trying to implement this exploit. That can work pretty well, but it's not iron-clad.

We should also expect there are vulnerabilities yet to be discovered/published. You've got to consider this probably isn't the last one, either in this hardware or future generations.

I'm starting to adopt the opinion that what we're likely to see is a CPU mode that's enabled for processing sensitive/secure data. It would disable speculative execution, branch-prediction, & prefetching, as well as using a dedicated cache set. The down side is that enabling such a mode basically announces to hackers what part of the code to target, but they've probably gotten pretty good at figuring that out, anyhow.

A similar approach would be to have a type of E-core with none of those features, which you'd schedule sensitive work on. Again, it would be a natural target for hackers, but that might be a worthwhile tradeoff. I guess it's a variation on the age-old dilemma of whether to put your valuables in a vault. It's definitely more secure, but also a natural target.
 
Last edited:
D

Deleted member 2731765

Guest
The researchers/devs again went silent on this one......

It is also possible to only run all cryptographic code on Icestorm cores, as the DMP does not activate on those. But there is a risk of reduced performance, and that in the future the DMP might silently be enabled on those cores as well.

So a long term solution would be to get finer-grain hardware control, e.g., to constrain the DMP to only prefetch from specific buffers or designated non-sensitive memory regions.

The hardware should more specifically expose to the software a way to selectively disable the DMP when running security-critical apps.
 

TechyIT223

Prominent
BANNED
Jun 30, 2023
277
66
760
I guess next gen M4 MAC chips will have hardware features and changes built-in for any similar vulnerability to crop up in near future?
 
D

Deleted member 2731765

Guest
I guess next gen M4 MAC chips will have hardware features and changes built-in for any similar vulnerability to crop up in near future?
Nothing can be said for sure right now. There might be some potential for silicon-level fixes, which may be implemented in future iterations of Apple's M series M4-chips.

However, the exact impact of disabling the prefetcher on performance still remains kind of uncertain. Since this vulnerability cannot be patched with software the real issue is with the microarchitectural design of these chips.

If Apple tries to fix it in the M4 chipset, without any major microarchitectural design, then it will surely see poor performance, meaning, an M4 chip will run like an M2 chip with a fix.
 
  • Like
Reactions: TechyIT223

TechyIT223

Prominent
BANNED
Jun 30, 2023
277
66
760
Nothing can be said for sure right now. There might be some potential for silicon-level fixes, which may be implemented in future iterations of Apple's M series M4-chips.

However, the exact impact of disabling the prefetcher on performance still remains kind of uncertain. Since this vulnerability cannot be patched with software the real issue is with the microarchitectural design of these chips.

If Apple tries to fix it in the M4 chipset, without any major microarchitectural design, then it will surely see poor performance, meaning, an M4 chip will run like an M2 chip with a fix.
Thanks🙂