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

Toggle sidebar Toggle sidebar
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.

www.prefetchers.info

UPDATE (March 26 2024)

Using Data Memory-Dependent Prefetchers to Leak Data at Rest
www.prefetchers.info


"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."
Click to expand...

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,"
Click to expand...
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:
  • Like
Reactions: JamesJones44, TechyIT223, mitch074 and 2 others
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.
 
jaquith said:
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.
Click to expand...
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
jaquith said:
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.
Click to expand...
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:
  • Like
Reactions: NinoPino and TJ Hooker
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.
 
  • Like
Reactions: TechyIT223 and bit_user
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?
 
TechyIT223 said:
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?
Click to expand...
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
Metal Messiah. said:
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.
Click to expand...
Thanks🙂
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom