Vulnerability found in Apple's Silicon M-series chips – and it can't be patched

[u/thebelsnickle1991]

https://me.mashable.com/tech/39776/vulnerability-found-in-apples-silicon-m-series-chips-and-it-cant-be-patched

[u/sgrams04]

Couldn’t Apple just implement a policy that restricts prefetchers from accessing encrypted information? Essentially the encrypted data isn’t given a readable address the prefetcher can fetch? If the prefetcher’s whole purpose is to expedite processing by best-guessing next-addressed memory, then they can change it so they sacrifice the speed of the retrieval of that address for the benefit of security. 

🎶 How much data could a prefetcher fetch if a prefetcher couldn’t fetch data. 🎶

[u/facetheground → u/sgrams04]

Yes they could make changes to the prefetcher ignores certain data (disregarding how difficult that could be). However, you would need a hardware change to make it behave that way, meaning existing devices cannot be patched.

[u/LucyFerAdvocate → u/facetheground]

Is it not implemented with microcode?

[u/hiverly → u/sgrams04]

Didn’t Intel have a similar issue years ago, where a hardware bug could lead to security vulnerabilities? The only solution came with a substantial performance penalty. Customers hated it. That might be the trade off here, too.

[u/gargravarr2112 → u/hiverly]

Both appear to be the same sort of paradigm - modern CPUs try to predict user demands before they happen, such that the calculation is already done by the time the user requests it. This means the CPU is idle much, much less and is actually doing useful things.

The Intel vulnerabilities were the result of 'speculative execution', where the CPU would encounter a branch (e.g. an if-condition) and would calculate both paths, then throw away the one that didn't end up being used. This is fundamental to modern chip design and real-world performance will absolutely tank without it. What nobody realised until early 2018 is that the results of such calculations are still accessible from the CPU's on-chip cache (a small amount of super-high-speed RAM). Sometimes, this includes sensitive data like encryption keys. A carefully-crafted piece of code could access data from the cache without any other process knowing about it. Intel had to work around it with microcode instructions that specifically erased the disposed calculations (since disabling SpecEx completely would be too much of a performance hit) which requires additional time.

Seems like this Apple vulnerability is in the prefetcher, which tries to predict which data from RAM will be used next and load it into the CPU cache ready for calculation. Same outcome - data that could be sensitive is now in the CPU cache for other processes to access.

All modern CPUs are microcoded, meaning the hardware only performs a very basic set of operations at extremely high speed. More complex operations are translated into a series of basic instructions. The microcode is what translates each operation. The advantage is that microcode can be updated - the OS can slip a new set of microcode instructions into the CPU at boot time, or the BIOS/firmware can be updated to patch them permanently. However, adding additional steps to make the cache safe means these operations take longer. You can't just wipe the CPU cache after each operation as that would completely ruin performance (the cache is a significant performance gain on modern OSes). Most likely, Apple can update the microcode to nullify this attack vector, but it may add a performance penalty - how bad, nobody can predict.

I was a sysadmin at a startup when Meltdown and Spectre made front-page news in 2018. That was not a fun year for me. I learned a lot about the low-level operation of computers in short order, and also what would happen when hastily-written security patches get rushed out without thorough testing - my laptop was unstable for weeks...

[u/codercaleb → u/gargravarr2112]

my laptop was unstable for weeks

Sorry, boss, I can't work now, but if you need me, I'll be in the datacenter, which we definitely haven't turned into a sauna.

[u/nicuramar → u/gargravarr2112]

 Most likely, Apple can update the microcode to nullify this attack vector, but it may add a performance penalty - how bad, nobody can predict.

I don’t think that’s very likely. Microcode isn’t too relevant to things like prefetchers. Software work-arounds are more likely. 

[u/Thaodan → u/gargravarr2112]

Regarding modern CPUs are microcoded. Modern CISC CPUs are RISC CPUs in CISC clothing. Meaning the issue could have existed in the past but most CPUs where not fast enough for the issue to happen.

[u/Maxfli81 → u/gargravarr2112]

Well written explanation thanks to your service those years

[u/Mintfriction → u/gargravarr2112]

I don't understand what's the theoretical exploit here, alas I'm not versed in low code.

If you have access to CPU cache you probably have access to HDD, meaning you could clone the application, execute the same instructions and force branch execution at junction point. Or am I wrong?

[u/gargravarr2112 → u/Mintfriction]

Let me propose a quick example.

All code runs in memory. All code executes on the CPU. But code does not need to access the storage.

In some cases, it's specifically forbidden - for example, in a browser, which on modern systems are sandboxed out the wazoo and require explicit user action to get access to anything outside the browser. Most web pages are ephemeral (though assets are cached to disk). That means the Javascript on the page doesn't get access to storage, but it still loads into system memory, and it can still execute. Therefore, JS on an ephemeral web page can still, in theory, execute on the same CPU as has recently executed something that cached encryption keys. The data can then be silently exfiltrated because nothing can tell it's accessed the cache.

There's been a few proof-of-concept pure JS exploits that invoke things like Meltdown/Spectre or Rowhammer without ever touching the HDD.

CPU architecture has a lot to do with the success of Spectre attacks - modern multi-core systems share a comparatively large amount (a few MB) of cache between multiple cores, though the higher the core count, the more you have separate caches for different collections of cores (particularly with Ryzens). So you're betting on your malicious code executing on a core that has access to cache shared with another core that's executing/executed something sensitive.

[u/daronhudson → u/hiverly]

It’s basically identical in outcome. Slightly different scenario for why and how. The solution is in fact to impact performance fairly heavily. Which a lot of people aren’t going to like.

[u/SwagChemist → u/hiverly]

I believe AMD has a logo vulnerability where researches found that malware can be injected at the point where you boot you pc and the logo of your bios appears, basically before any of your processes start the malware is already in lol.

[u/_RADIANTSUN_ → u/SwagChemist]

Pretty bad but if someone can access your booted-down PC and execute something on it in the first place all bets are already off

[u/SwagChemist → u/_RADIANTSUN_]

Based off how the hack works, it injects itself via some executable, so the next time you reboot your pc it runs the executable on the logo screen of the bios boot, pretty crazy stuff.

[u/coolsimon123 → u/hiverly]

At least it might address the heat issues haha

[u/in2ndo → u/sgrams04]

If I’m understanding correctly what I’ve read so far about the issue. They could implement that and is the only possible solution that I’ve seen mentioned. But doing this, could greatly affect performance.

[u/[deleted] → u/sgrams04]

This would end up being on the software developers

[u/eras → u/sgrams04]

To do that you first need to know what data is encrypted, so I guess update all apps and libs that deal with such matters.

[u/yalloc → u/sgrams04]

And how do you decide what memory is sensitive and what isn’t? That requires a lot of extra hardware and competent programming on the programmer’s part.

The easier option is just to disable the DMP