Spectre comes back from the dead to haunt Intel chips

AppleInsider

Security researchers have found new versions of chip flaws affecting Intel and AMD processors that get around existing mitigations for Spectre attacks, resurrecting vulnerabilities that may affect Intel-based Macs.

In 2018, an Intel chip kernel flaw was found that allowed attackers to gain access to protected data, which could include passwords and application keys. While patches and mitigations were put in place to block the so-called "Spectre" attacks from happening, researchers have determined the efforts aren't enough to prevent the attacks entirely.

In a paper published by researchers from the University of Virginia and the University of California, at least three new versions of Spectre attacks have been found affecting micro-op caches in Intel and AMD processors.

Crucially, the three methods determined by the researchers get around previous Spectre defences that prevented such data leaks. This means current processors are vulnerable to the Spectre-like attacks, despite their anti-Spectre protections.

The researchers have already disclosed their research to Intel and AMD, reports Phoronix, but so far there have yet to be any kernel patches or microcode updates distributed by either side ahead of the public disclosure.

Part of the problem is that the fix may introduce a "much greater performance penalty" than previous mitigations. Example fixes include flushing the micro-op cache at domain crossings, or to instigate privelige level-based partitioning of caches.

While the disclosure is quite damning to Intel and AMD, the high difficulty of pulling off an attack makes it unlikely that it will affect many people at all. To do so, the malware would have to thread the needle of getting past all existing security measures included in operating systems, before even attempting to use any of the vulnerabilities in the first place.

At this time, it is unknown if the vulnerabilities affect Intel-based Macs, but it is likely that they are at a minimal risk of attack. With Apple's move to Apple Silicon and its home-grown architecture, new Macs aren't likely to be directly affected by the new discovery.

That being said, Apple did introduce fixes to combat Spectre and "Meltdown," another chip flaw discovered at the same time in 2018. Mitigations were issued in macOS, iOS, and tvOS, indicating Apple's A-series chips were also vulnerable at the time.

The Spectre headache was a long-running problem for Intel. More Spectre-style vulnerabilities were disclosed in a second wave in mid-2018.

An inevitable class-action lawsuit against Apple was attempted, claiming the company's handling of the vulnerabilities had slowed down A-series chip products. By January 2019, the case was dismissed for a lack of standing.

Update May 3, 3:44 PM ET Intel believes that there are already sufficient protections with existing mitigations, despite the researchers differing on this point.

"Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance," Intel said in a statement. "Software following our guidance already have protections against incidental channels including the UOP cache incidental channel. No new mitigations or guidance are needed."

Update May 4, 11:45 AM ETAshish Venkat of the UVA School of Engineering responded to Intel's statement on Tuesday, insisting that it is a hardware issue that needs to be secured, rather than something that can be countered with changes in software development.

"Certainly, we agree that software needs to be more secure, and we agree as a community that constant-time programming is an effective means to writing code that is invulnerable to side-channel attacks," the UVA statement reads. "However, the vulnerability we uncover is in hardware, and it is important to also design processors that are secure and resilient against these attacks."

"In addition, constant-time programming is not only hard in terms of the actual programmer effort, but also entails high performance overhead and significant deployment challenges related to patching all sensitive software. The percentage of code that is written using Constant Time principles is in fact quite small. Relying on this would be dangerous. That is why we still need to secure the hardware."

Stay on top of all Apple news right from your HomePod. Say, "Hey, Siri, play AppleInsider," and you'll get latest AppleInsider Podcast. Or ask your HomePod mini for "AppleInsider Daily" instead and you'll hear a fast update direct from our news team. And, if you're interested in Apple-centric home automation, say "Hey, Siri, play HomeKit Insider," and you'll be listening to our newest specialized podcast in moments.

jdb8167

I know that Apple's Arm CPUs use micro-ops but I don't know anything about if or how they are cached. The caching of micro-ops is the source of this vulnerability. In general RISC CPUs have much simpler decoding so it is possible that micro-ops aren't cached at all or the cache structure is much simpler. Someone with more knowledge of Arm CPU Architecture should chime in.

Edit: And apparently SMT (also known as hyper-threading) is involved. Since Apple's ARM SoC cores don't use SMT, it looks like they are safe from this.

InspiredCode

jdb8167 said:

I know that Apple's Arm CPUs use micro-ops but I don't know anything about if or how they are cached. The caching of micro-ops is the source of this vulnerability. In general RISC CPUs have much simpler decoding so it is possible that micro-ops aren't cached at all or the cache structure is much simpler. Someone with more knowledge of Arm CPU Architecture should chime in.

Edit: And apparently SMT (also known as hyper-threading) is involved. Since Apple's ARM SoC cores don't use SMT, it looks like they are safe from this.

The memory model of ARM makes these types of attacks more difficult. Micro-ops are fixed length and shouldn’t require much caching unlike Intel/AMD. This is also one of the main reasons M1 has such amazing single threaded performance since it isn’t limited by the decoder. The x86 ISA should die already.

jdb8167

InspiredCode said:

jdb8167 said:

I know that Apple's Arm CPUs use micro-ops but I don't know anything about if or how they are cached. The caching of micro-ops is the source of this vulnerability. In general RISC CPUs have much simpler decoding so it is possible that micro-ops aren't cached at all or the cache structure is much simpler. Someone with more knowledge of Arm CPU Architecture should chime in.

Edit: And apparently SMT (also known as hyper-threading) is involved. Since Apple's ARM SoC cores don't use SMT, it looks like they are safe from this.

The memory model of ARM makes these types of attacks more difficult. Micro-ops are fixed length and shouldn’t require much caching unlike Intel/AMD. This is also one of the main reasons M1 has such amazing single threaded performance since it isn’t limited by the decoder. The x86 ISA should die already.

I was reading as much of the white paper as I could understand without doing further research and my conclusion is that even if the M1 is using a micro-op cache, the authors are using the x86 ISA complexity as a way of detecting micro-op cache hits and misses. That complexity isn't there in the M1 or any Arm RISC system. I won't say this attack is impossible on Apple Silicon but as you say, it would be more difficult--probably much more difficult. Add in that 1 or their two attacks is via SMT, I think ASi is probably pretty safe from this.

maciekskontakt

Author is wrong. No it is not Spectre but Meltdown. Please focus on the problem. Spectre is based on predictive branching and affects other processes. Meltdown is ability to escalate memory protection and enter kernel space. Two different things.

While Intel, AMD and ARM processors are affected by Spectre, AMD has never had Meltdown issue.

fastasleep

maciekskontakt said:

Author is wrong. No it is not Spectre but Meltdown. Please focus on the problem. Spectre is based on predictive branching and affects other processes. Meltdown is ability to escalate memory protection and enter kernel space. Two different things.

While Intel, AMD and ARM processors are affected by Spectre, AMD has never had Meltdown issue.

Then why does the linked paper which is the subject of this article mention Spectre 30 times and Meltdown is only mentioned three times in the citation footnotes?

michelb76

jdb8167 said:

I know that Apple's Arm CPUs use micro-ops but I don't know anything about if or how they are cached. The caching of micro-ops is the source of this vulnerability. In general RISC CPUs have much simpler decoding so it is possible that micro-ops aren't cached at all or the cache structure is much simpler. Someone with more knowledge of Arm CPU Architecture should chime in.

Edit: And apparently SMT (also known as hyper-threading) is involved. Since Apple's ARM SoC cores don't use SMT, it looks like they are safe from this.

Too bad they didn't test the M1.
These things are indeed hard, but there's always something: https://security.googleblog.com/2021/03/a-spectre-proof-of-concept-for-spectre.html

beowulfschmidt

fastasleep said:

maciekskontakt said:

Author is wrong. No it is not Spectre but Meltdown. Please focus on the problem. Spectre is based on predictive branching and affects other processes. Meltdown is ability to escalate memory protection and enter kernel space. Two different things.

While Intel, AMD and ARM processors are affected by Spectre, AMD has never had Meltdown issue.

Then why does the linked paper which is the subject of this article mention Spectre 30 times and Meltdown is only mentioned three times in the citation footnotes?

Because obviously, these university researchers, who spend much of their lives doing this sort of thing, know nothing.