- Joined
- Sep 26, 2021
- Posts
- 6,654
- Main Camera
- Sony
All AMD Zen CPUs Vulnerable, Might Need to Disable SMT
Side-channel SQUIP vulnerability affects all SMT-enabled Zen CPUs.
www.tomshardware.com
Another side channel attack: AMD this time
- Thread starter Cmaier
- Start date
www.tomshardware.com
- Joined
- Sep 26, 2021
- Posts
- 6,654
- Main Camera
- Sony
Yeah, I’ve mentioned it before - SMT better be very much worth it performance-wise, because it’s almost impossible to insulate it from side channel attacks. Most of the things you would do to prevent them would also hamstring performance (like resetting all state elements every time you switch threads, not starting the next thread until all instructions of the prior thread are fully retired, etc. etc.)
- Joined
- Sep 26, 2021
- Posts
- 6,654
- Main Camera
- Sony
it’s not an area-efficient solution to the x86 problem of difficult instruction scheduling, but it likely is less susceptible to side-channel attacks. They can also then quote some bullshit “peak ops” number as if they can keep all the cores busy.
Colstan
Site Champ
- Joined
- Nov 9, 2021
- Posts
- 822
I know that you're not, in general, a security engineer. However, you have mentioned in the past how you've taken a specific interest in side-channel attacks of this nature. From what I gather, you and other knowledgeable folks have said that Apple's performance cores would see little to no benefit from SMT, and perhaps even a performance hit, under some circumstances. I believe that you've also said that, again under special circumstances, the efficiency cores could theoretically benefit from some form of SMT, but that's not entirely certain. Please correct me if I am wrong and am misremembering what has been said on this subject. Even if the E-cores could benefit in some way, or even the P-cores in some future implementation, I haven't seen anyone knowledgeable suggesting that Apple's engineers should put effort or resources into SMT, both in terms of manpower and die space, which would be better served elsewhere.
Again, correct me if I am wrong about anything I stated above. Regardless, how much impact have these side-channel vulnerabilities had in the real world? Benchmarking has shown that x86 CPUs can take a substantial performance impact from these patches, mainly in the form of a BIOS microcode or Windows update, after applied to affected systems. Sometimes, the impact is as great as perhaps an entire CPU class or more, such as the difference between an i9 and an i5. I know I wouldn't be pleased if a UEFI update, assuming the motherboard manufacturer actually supplies one, gimped a two-year old CPU designed to compete at the high-end and then suddenly became the equivalent of today's budget i3 chip.
I get that many of the performance tricks done by CPU engineers are going to potentially have vulnerabilities, Intel seems to have applied more cheats than anyone else, including AMD, but nobody is immune. Dumping UEFI, moving users to iBoot, and avoiding SMT mine fields are part of Apple Silicon's current and future benefits. Apple doing their best to avoid unfixable vulnerabilities, such as those within the T2, are another. (You pointed out that the much ballyhooed Nuvia chips that Qualcomm is working on is being spearheaded by "trade secrets guy", who oversaw the T2 and hence the permanent flaw found within its design.)
Once again, if I am getting the details wrong, then feel free to correct me. I think the security benefits of moving the Mac platform over from the Swiss cheese platform that x86 has become, to Apple's own proprietary implementations are obvious. The benefits of controlling the microcontrollers running device I/O, all the way up to the operating system and primary applications, is clear.
What I am personally unclear about is how much of an impact these side-channel attacks have had in the real world. Sure, nation states and specialized mercenary groups that sell to the highest bidder are going to take an interest in this. However, they don't target the average user who has a questionable collection of Blu-ray rips with an "FBI warning" label at the beginning, important tax documents that show they shave a little off from the tax man by giving to a shady local charity, thusly not rendering unto Caesar, or not exposing their embarrassing fetish videos involving green jell-o and an extensive spatula collection.
In other words, specialized SMT vulnerabilities may be useful for espionage or blackmailing government officials, or for use by said governments against organized crime, human rights activists in authoritarian jurisdictions, or ways to make money by auctioning off an exploit to the highest bidder. What I am wondering about, and genuinely curious in regards to, is how these side-channel attacks actually impact the average user. Like most people, I'm an entirely uninteresting target. Scammers and malcontents are likely interested in taking advantage of me for financial gain, not because of industry trade secrets, political activism, or having enemies in high places. Concerning regular people as targets, bad guys want access to bank accounts, credit cards stored on Amazon, or scamming people with a fake Ebay listing, replete with poor spelling and all.
In that regard, it seems much simpler to get the average user to install a new "emergency" update to Adobe Flash, a one-click jail-break for Android, or an app that gives the user easy access to Sexy Singles in Your Area™. In other words, why bother with side-channel attacks when simple social engineering will do?
Or is it somewhere in-between that I am missing? If anyone has thoughts or insights on the matter, then I'd like to hear them. From what I gather, it just seems that many, if not most of these SMT attacks are more academic, rather than useful to criminals. Perhaps I am incorrect, but if side-channel attacks are of significant utility, then it's more likely to appeal to a North Korean agent funded by Western tourism to hack their homeland defense department's computers powered by massively multicore Xeons, rather than Aunt Mabel falling prey to some slob living in his mother's basement who targets vulnerable people using poorly worded e-mail attachments. Or perhaps there is a middle-ground that I am overlooking?
Again, from what I can tell, there appears to be many reasons that Apple would have no motivation to bother implementing SMT within Apple Silicon, and even the most powerful of Macs may not benefit from it. That being said, are side-channel security issues as big a factor as news headlines make them out to be?
Yeah, i agree. Hyperthreading might be better in terms of efficiency but the past 5 years has proven that making it actually secure is too difficult.
And the days of not needing to protect processes from each other, even on a single user box are well and truly over, given everything is networked. I mean....
4783 threads on my reasonably lightly loaded home-lab box.... even single user machines these days are running many, many potentially hostile threads inside their browser tabs.
- Joined
- Sep 26, 2021
- Posts
- 6,654
- Main Camera
- Sony
Yep.
My introduction to side channel attacks occurred while in law school. My civil procedure professor was the chief judge for the northern district of california. He scheduled a hearing on a motion to dismiss to occur in our classroom, which was pretty crazy. A famous security guy was on one side of the lawsuit and he was suing a particular company for techniques they allegedly used to avoid a side channel attack that he discovered - he had a bunch of patents on ways to avoid the attack.
After the hearing ended, the lawyers all left, and the professor/judge asked me what I thought - he knew I worked as a CPU designer during the day and was attending his class at night. I told him I thought that there was a very obvious workaround for the attack and that if the inventor thought he had a patent on it, my own work would certainly be prior art to that patent. (the technique I had in mind was differential logic, which avoids fluctuations on the power rail which can be monitored as a side channel - I didn’t invent it, but I certainly published a lot about it years before any possible patents on using it to avoid side channel attacks).
Here’s where it gets weird. A couple years later I took a paid sabbatical from AMD for two months and went to work at a law firm for the summer. About a year after that I went to work at that law firm full time. But just before I got there, they hired a guy from another law firm, who moved from Pittsburgh to California. It turns out he was the guy who was defending against the lawsuit, and that suit was still going on, in front of the same judge. Needless to say, I ended up defending against that lawsuit, and as part of that we submitted my own publications as prior art to his patents. Which is why a bunch of his newer patents now have my name listed in them as prior art considered by the patent examiner.
Anyway, there was a time period when I was probably the only person at AMD thinking about side channel attacks, and only because I was in law school at night and had seen a hearing about one such attack.
Some of the attacks have been more impactful than others. At least one could be triggered in a drive-by fashion, for example by viewing a website with malicious javascript in it. Others can occur pretty easily in server farm settings where you are sharing a machine with other users. And some are probably not very useful other than to nation-states or in situations where a computer has really super valuable information on it and for whatever reason simpler attacks aren’t possible.
Manu? He’s the guy I worked with pretty closely at AMD.
Well, if you can have malicious attack that only requires that someone browse to a website, perhaps even a legitimate website that has had a malicious ad served to it via an ad network, that’s potentially even easier. Social engineering may always be the easiest and cheapest way to get in, but some of these side channel attacks are pretty wild, even allowing you to get information off of airgapped computers! I’ve seen attacks that rely on fan noise, input power supply fluctuations, etc.
As a consumer who probably does internet banking on their machine, are you willing to bet your entire bank balance on these side channel attacks being nothing to worry about?
Never mind enterprise doing virtualisation of hundreds of virtual servers on a single box.
Personally i'll take the potential performance/efficiency compromise of not using SMT (if i was making a design trade-off) - for most people processors have been fast enough for a decade now; plenty of people are still running i5-2600k or i7-2700k even on their gaming rigs. Sure there are performance demands beyond that today but most of those are handled by GPU acceleration or add on co-processors or dedicated instructions these days.
Last edited:
Colstan
Site Champ
- Joined
- Nov 9, 2021
- Posts
- 822
You had mentioned previously about your focus on side-channel attacks, but I had no idea the extent which you were familiar, and the wild story behind it. That's like something out of a technical courtroom drama. It sounds like you were way ahead of the industry on this issue, perhaps a little too far ahead, because it didn't become a serious problem until the past half-decade or so. While low-level CPU exploits have been a problem for everyone, it seems like Intel was the one to play fast and loose the most, at least it appears that way from publicly available information. They cut a lot of corners and now it's biting them in the ass, not that everyone has a perfect record, Intel just seems the most egregious.
While the drive-by attacks may be more impactful, I would think they would be patched reasonably quickly. What I find the most terrifying is the idea that you have a VM hosted on a third-party service. A malicious actor just so happens to rent some VM space on those same servers, in an attempt to target other VMs, perhaps a specific organization, rather than a fishing expedition. I realize that it's more complex than that, and not easy to do, but a determined malicious actor could possibly achieve it.
I would imagine that if you're being targeted by a nation-state then you've got bigger problems than a few edge case side-channel attacks. Not something pleasant to think about.
Yeah, in another discussion you referred to him as "trade secrets guy". There was a lot of "Apple is doomed" chatter over at the other place when the ex-Apple engineers left to form Nuvia, and then again when Qualcomm purchased them. You thoroughly debunked that notion when you went through your personal list of colleagues you knew that are still working for Apple, hence ruining the narrative that the brain drain isn't as impactful as the doom sayers had predicted.
There are people who still insist that the M2 was a stopgap product and rushed out because the original design (whatever that supposedly is) couldn't be completed because the alleged sudden loss of key engineering staff, hence the "minor improvements" with M2. Even as a total laymen on such matters, I know that's not how this works, and it takes years for an SoC as complex as the M-series to go from development to release in actual products. On top of that, the M2 has substantially reproducible improvements, such as a doubling of GPU performance in some games, but there was a narrative that formed early on, egged on by Youtubers with click-bait headlines, who clearly have no idea what they are talking about, that somehow persists among a subset of chicken littles in the community.
Also, you pointed out that the permanent security flaw inside the T2 was under the supervision of trade secrets guy. He may be a good engineer, but still human, and despite losing him, Apple has other talented engineers to fill his shoes. I would imagine that he probably regrets taking technical papers with him from the notoriously secretive Apple before leaving for Nuvia.
Definitely not. My intent wasn't to downplay the threat and imperative in fixing side-channel attacks. I was simply curious about the relative complexity and what level of skill is required compared to simple social engineering.
As I said to @Cmaier above, that's far more concerning, considering how much harder I would think it is to pinpoint the intrusion, compared to a mass attack with indiscriminate drive-bys. I would hope that every organization has a plan for this, especially given how publicized SMT attacks are, but then there are still organizations that require employees to use Internet Explorer.
I fully agree. I'm a reasonably paranoid person, not tin-foil hat wearing levels, but I want all the fixes applied despite performance hits, even if my i3 Mac mini gets downgraded to a, well, even slower i3. The only benefit to a pokey i3 is that it doesn't use SMT, hence it may not be vulnerable to some of those issues. SMT has always come off as a bit of a kludge, something that @Cmaier and other engineers have pointed out in regards to x86 and its many deficiencies.
Like I said, I'm not at all trying to downplay the severity of these vulnerabilities, just trying to understand the nature of the threat and how it compares to more simple threats like social engineering or traditional malware. It's more evidence, in my mind, that the sooner Apple moves the entire Mac user base to Apple Silicon, the better it will be for platform security. Not having to deal with the Swiss cheese mess of UEFI, SMT vulnerabilities, and duplication of efforts with parallel x86/Arm compatibility, have to be positives on many levels. (That, and the T2 security flaws oversaw by trade secrets guy will go away once the T2 gets simultaneously deprecated alongside Intel.)
Every processor has flaws, we all know that, but reducing the attack surface by transitioning to Apple Silicon should be substantial. Many a straw man will perish along the way, but I think it's for the better to kill off Intel Macs as soon as reasonably possible. There are still folks over at the other place who insist that the 2019 Mac Pro will receive new versions of macOS until 2029 or 2030. Apple will also provide every Apple Silicon Mac Pro user with a free pony, too, to entice them to make the switch.
Keep in mind that I say this as someone who is still on an Intel Mac, I plan to use it for at least another year or two, but understand that Apple Silicon is the future, and probably a better one overall, for the Mac and the vast majority of Mac users.
Anyway, thanks to @Cmaier and @throAU for the thoughtful responses, much appreciated.
Several of these side-channel attacks have been demonstrated using Javascript unfortunately, which means that one could potentially deploy via a browser plugin, compromised web-server (e.g., compromise a forum web-server via some other exploit, to have the server insert a malicious javascript widget into every page it serves, to every user), etc.
This is how Nimda spread itself to a degree, way back. But that was just a software exploit, not something that can exploit flawed hardware.
Nimda - Wikipedia
Just think how bad that could be if it was used to collect in-memory security credentials from every user hitting a web server. Probably just as effective, and far less risky than targeting an enterprise directly. Individual users are far less likely to know how to detect it and what to do if they do discover it.
Last edited:
KingOfPain
Site Champ
- Joined
- Nov 10, 2021
- Posts
- 567
I agree with Cliff that social engineering is probably much easier to accomplish than getting some of these vulnerabilities to work. But JavaScript and cloud VMs are probably the biggest risks. Doesn't some browser (Edge?) now have the option to run JavaScript in an interpreter instead of JIT compiled?
What I really wonder is how many vulnerabilities Apple Silicon CPUs have, since I believe there isn't much information.
As for the original ARM implementations, basically every CPU core with out-of-order execution and more than 8 pipeline stages has some form of vulnerability:
developer.arm.com
But even if the CPUs were totally secure, there is still rowhammer to get information from the memory directly.
What I really wonder is how many vulnerabilities Apple Silicon CPUs have, since I believe there isn't much information.
As for the original ARM implementations, basically every CPU core with out-of-order execution and more than 8 pipeline stages has some form of vulnerability:
Speculative Processor Vulnerability
Vulnerability of Speculative Processors to Cache Timing Side-Channel Mechanism.
developer.arm.com
But even if the CPUs were totally secure, there is still rowhammer to get information from the memory directly.
- Joined
- Sep 26, 2021
- Posts
- 6,654
- Main Camera
- Sony
Just to be clear, I don’t know who did what re: trade secrets. At the time I first mentioned it, I only knew what Apple had alleged in its Complaint, which I had read. Now I don’t even recall what the allegations were. They may have been more along the lines of using Apple’s resources to build the company. I don’t remember.
In general these vulnerabilities will be found by third parties and we tend to find out about them. Out of order CPUs don’t inherently have side channel problems, at least I haven’t seen any research that suggests that. The attacks you link to on Arm’s page seem to be implementation-specific (though they may affect all of Arm’s own implementations, that doesn’t mean they affect Apple’s). Things like speculative loading of inaccessible data is a design choice - you implemented the CPU in such a way that the load/store unit checks performs a load without first checking bounds, as a performance enhancement or design simplification. (In that particular case, you might not need to do that on M1/M2 because of higher memory bandwidth). Or “bypassing of stores by younger loads despite the presence of a dependency” - same deal. That’s just design laziness, and I can’t see any benefit from doing that. “speculatively executing the instructions linearly in memory following an unconditional change in control flow” is another thing that makes no sense to me. If you know you have an unconditional branch, why would you keep executing the instructions in sequence (“speculatively“) after the branch instruction instead of branching? That just gives you more to unwind. I designed a lot of out-of-order machines and we wouldn’t do that.
KingOfPain
Site Champ
- Joined
- Nov 10, 2021
- Posts
- 567
I know that Apple Silicon has a totally different implementation that the standard ARM cores, which is why I would be interested if they have vulnerabilities, too.
I only assumed that out-of-order execution and longer pipelines were an indicator, because, e.g. Cortex-A57 has vulnerabilities, but Cortex-A53 has not. The latter has a much shorter pipeline (almost half the stages, although still long enough to count as a "super pipeline" similar to the MIPS R4000) and it has no out-of-order execution, since it's the low-power core.
I almost wanted to ask if there is any speculative load operations without out-of-order execution, but then I remembered that IA-64 defined an explicit instruction for that, IIRC.
But I'm derailing the thread that started out about AMD. Sorry about that...
I only assumed that out-of-order execution and longer pipelines were an indicator, because, e.g. Cortex-A57 has vulnerabilities, but Cortex-A53 has not. The latter has a much shorter pipeline (almost half the stages, although still long enough to count as a "super pipeline" similar to the MIPS R4000) and it has no out-of-order execution, since it's the low-power core.
I almost wanted to ask if there is any speculative load operations without out-of-order execution, but then I remembered that IA-64 defined an explicit instruction for that, IIRC.
But I'm derailing the thread that started out about AMD. Sorry about that...
- Joined
- Sep 26, 2021
- Posts
- 6,654
- Main Camera
- Sony
Nobody here cares if the thread evolves to talk about other chips
Anyway, it certainly is easier to cause a side channel vulnerability with out-of-order execution, but that doesn’t mean out-of-order execution is always vulnerable.
And, yeah, you can do speculative loads even with an in-order design, and it’s a good thing to do from a performance perspective. Just like you can do speculative execution of branch targets in an in-order design.
KingOfPain
Site Champ
- Joined
- Nov 10, 2021
- Posts
- 567
Good to know, let's talk about Pringles then ;-)Nobody here cares if the thread evolves to talk about other chips
Anyway, even the best designers are only human and there can either be errors or comprimises between speed and security that cause these vulnerabilities.
I remembered stumbling across an article covering Itanium being immune to Spectre/Meltdown, so I searched for it:
Apparently, Bill Worley, the chief architect of Itanium, was obsessed with security. But a few things don't fit here:
complexity is the enemy of security
I would say that's true, but I wouldn't exactly call Itanium "not complex" either.
This raises the question: can we really meet the needs of 21st century computer security with a 44-year old architecture? The answer has been repeatedly found to be “no” – Spectre and Meltdown are just the latest in a long line of goofs, oopses, and oversights.
As much as I'm not a fan of the x86 architecture, the problem here is the implementation, not the architecture itself. Otherwise AMD wouldn't have a lot less vulnerabilities compared to Intel.
I'm guessing the architecture doesn't make it easy, but it depends on the effort you put into the implementation how secure the result is.
Nobody here cares if the thread evolves to talk about other chips
I'd go so far as to say that comparison to other architectures is especially relevant. It may have started out about AMD, but comparing what they did/did not do right/wrong as demonstrated by how others have fared is, I believe the point of this discussion. Hence, discussion of other processors is inevitable.
