AMD Flaws, Fastforwarding to 2020: Any concerns with Zen 2 / x570 Chipsets?

[rugabunda]

NSA says "Purchase business-class AMD machines that lack "gamer" features such as overclocking, firmware modding support (etc)

Here is the NSA's github guide for Firmware: https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance

3.2 Ryzenfall, Chimera, Fallout, and Masterkey

Together, these four named attacks constitute what is publicized as "AMD Flaws" and over a dozen vulnerabilities. Many vulnerabilities assume the compromise of administrator credentials or completely inept software-vetting processes. Some of the vulnerabilities are a direct result of debug features left enabled for use in advanced system tweaking common in the overclocking and gaming communities.

To mitigate AMD Flaws, purchase business-class machines that lack "gamer" features such as overclocking, fan control, custom thermal management, RGB lighting, and firmware modding support. Also ensure that all firmware, microcode, and software updates are applied. Carefully analyze software before using it in conjunction with the AMD Secure Processor (SP) or Platform Security Processor (PSP) protected enclaves.

I GUESS they mean HP all in one PC/laptops exclusively. Anything future Zen 2 that is offered under the same product lines listed here should be the most secure platform you can get.

HP's Chimera/Fallout/Ryzenfall/Masterkey was patched in products that date back as far as 2015:

HP ProDesk 405 G2, uses "AMD Pro A8-8600B" cpu, released on 06/03/2015
HP Slimline 450, AMD E1-6015; 2nd quarter 2015
HP OMEN 870-0xx patch features an intel chipset (obviously a patch for Asmedia's chimera, which affects both AMD & Intel chipsets)
HP Pavilion 24-xa0xxx patch features an intel chipset (obviously a patch for chimera, which affects both AMD & Intel chipsets)

Meanwhile, I had spoken to Asus in First quarter of 2019, they had told me they were STILL working on patches for these fatal exploits in their latest motherboards, some released in 2018. Meanwhile patches were already released months earlier by the only company that confirmed AMD Flaw patches were released, HP. I was unable to get any straight answer or response from MSI, Gigabyte, or Asrock inquiring into AMD flaw patches.

However, I was told by Asus quote: "Once the patch has passed through quality assurance, it will then be distributed to AMD’s OEM partners through AGESA"

As of x570 AMD stopped outsourcing their chipset to Asmedia and started printing their own in-house, including USB & PCIe chipset. ASMedia was responsible for chimera, a back door built into their USB chipsets hardware and firmware... affecting USB ASM1042, ASM1142, ASM1143. SATA, ASM1061, among others. This one I assume we can be confident is taken care of.

I assume the Zen 2 platform and x570 will have patched all of these flaws. Should we take the NSA's advice and use business class machines ONLY with the x570 chipset and avoid the gaming rig? Should we wait until Zen 3? Any tips?

 

[Deleted member 185158]

Oh no, what does this mean??!!

No seriously, I'm not holding my hands to my cheeks......

 

[tabascosauz]

X570 eliminated Promontory's flaws, because it's literally a Zen 2 client I/O die manufactured on the 14nm process normally used for EPYC 7xxx I/O dies. Problem is, a good chunk of the Zen 2 userbase doesn't use the Bixby chipset, because they opt for B450/X370/X470, which is obviously still Promontory.

NSA's blanket suggestion to essentially avoid aftermarket hardware sounds a little stupid, but it's not entirely without merit. Motherboard vendors are notoriously bad at releasing microcode and BIOSes to patch vulnerabilities in older hardware. Look at how many years the Intel vulnerabilities have been in the media. They just can't be bothered; there are so many boards, and by their calculations, so few users who might actually suffer security issues in their uses. I'd bet that in 2020, they probably just assume that those hardware generations have either died off / are in the process of dying / have been replaced by newer hardware. The Microcode Boot Loader tool, found right here on TPU, is proof of what users had to do to fill that void.

My main concern lies with PSP. It's, at its core, AMD's take on the Management Engine, and from its closed-off design, there's both very little information available on it and a very high likelihood it'll suffer the same fate as Intel's ME. "Our design works differently than Intel, and isn't vulnerable" isn't going to work here.

Problem there is, Intel is cagey and scummy when it comes to exploits, but they pay people to find the vulnerabilities. AMD doesn't, and AMD's first reaction to any vulnerability-related discussion in the past is "oh, we're not Intel, we're fine. We're fine. Listen, really, there aren't any problems with our products."

Muddying the waters further is the whole controversy around whether CTS Labs really exists, and/or whether they're a paid Intel shill. They probably are, but Ryzen isn't perfect. I can't remember the exact vulnerability affecting Zen and Zen+, but AMD's response was basically "hey look, it's been completely fixed with Zen 2, so you should upgrade to Zen 2."

@biffzinker I don't think it was the RDRAND bug, since there were still reports on Zen 2. Probably not segfault, I'm thinking of an article most likely on Anand that was published between Zen+ and 2.

 

[GLD]

I have an Asus Tuf X570 board and a Ryzen 3600 on the way. Seeing as the X570 chip is built by AMD themselves, I fell secure, and happy for the new kit.

 

[biffzinker]

I can't remember the exact vulnerability affecting Zen and Zen+, but AMD's response was basically "hey look, it's been completely fixed with Zen 2, so you should upgrade to Zen 2."

The segfault issue with first generation Ryzen?

AMD Confirms Linux Performance Marginality Problem Affecting Some, Doesn't Affect Epyc / TR - Phoronix

www.phoronix.com

AMD's RDRAND instruction?

AMD Ryzen 3000 series CPUs can't do Random on boot causing Boot Failure on newer Linux distributions

linuxreviews.org

How a months-old AMD microcode bug destroyed my weekend [UPDATED]

AMD shipped Ryzen 3000 with a serious microcode bug in its random number generator.

arstechnica.com

 

[Fourstaff]

What are the odds that Zen 2 platform will have patched all of these flaws? Should we take the NSA's advice and use business class machines ONLY with the x570 chipset and avoid the gaming rig? Any tips? Should we wait until Zen 3?

Different people will have different risk tolerances. For example I don't have anything super important on my PC, losing it is no big deal for me. However, a lot of people manage their business/life around their machines. These people will need to pay more attention as an unlucky attack will turn their life upside down. Using x570 will eliminate some risks, but will certainly not eliminate the yet to be found ones. Best to do proper backups and practice good security habits.

 

[Sybaris_Caesar]

I wonder now how long before a mod locks the OP from posting. I'm from a third world Asian country that has no Jewish population to speak of but even I'm squeamish about saying anything negative about Israelis on the Internet.

 

[R-T-B]

Lets leave political theories and conspiracies out of this. Also lets refrain from attacking complete ethnic groups over theoretical security flaws.

All I have to say re the supposed NSA guidance is consider their use case. Does it match yours? If not, quit worrying. No one is going to go to this trouble over you and most of these vulnerabiluties are old news at this point.

 

[Sybaris_Caesar]

Mayhap OP's a contractor/supplier for some Irani department or agency looking to upgrade their systems, who knows?

Lets leave political theories and conspiracies out of this.

All I have to say re the supposed NSA guidance is consider their use case. Does it match yours? If not, quit worrying. No one is going to go to this trouble over you and most of these vulnerabiluties are old news at this point.

 

[R-T-B]

Excuse me, stay on topic. This is not your thread to hijack. This thread is about the facts and truth regarding the situation, not political correctness or avoiding obvious facts and historical truth. Start your own thread if you want to boss people around and dictate the content of the discussion.

Then don't go offtopic with theories you can't substantiate. My comment was out of a desire to stay on topic, not viceversa.

I personally don't like the PSP because it is little understood (other than portions coming from Qualcomm patents, and not good ones) and can't be disabled like Intel's solution. Both are equally bad in concept, but at least one can eventually be disabled.

 

[R0H1T]

CTS disclosed their flaws prematurely which gave AMD someone to blame and excuse their PR in dealing with this; perhaps not a good move, but they're making up for it! My god they are doing a great job with their latest architecture and cpus.

No CTS was a hit job, that's what it was. If you're giving that kind of leeway to CTS then there's a host of other companies which could be hit with multiple zero day attacks, including yours truly competitor A

CTS did no one any good, except trying to make a big splash outing "major" flaws. The fact that they've done nothing since will solidify many theories about their true intentions!

 

[R-T-B]

No CTS was a hit job, that's what it was. If you're giving that kind of leeway to CTS then there's a host of other companies which could be hit with multiple zero day attacks, including yours truly competitor A

It also was a real set of vulnerabilities. Overblown perhaps, but lets please analyze the facts of the security issues here rather than taking sides, political or brand-related.

My opinion is that short of local attacker access, or a specially prepared infected usb device, these vulnerabilities are nothing for end users to worry about.

 

[R0H1T]

Sure they were & then after the much publicized "flaws" went public not a peep from CTS. What are they doing now, what's their history? If anyone had to be blamed in that fiasco it was CTS, not in the least because their disclosures were not in good faith let alone responsible.

 

[R-T-B]

Sure they were & then after the much publicized "flaws" went public not a peep from CTS. What are they doing now, what's their history?

Frankly, in relation to the OPs query, that is completely irrelevant.

 

[AlienIsGOD]

Leave Jewish ppl out of tech conversations please. I could care less if you are using it as an analogy... Also don't tell ppl what to comment or not comment as it makes you look pushy and rude as a new member.

 

[rugabunda]

@R-T-B did you end up starting that new thread on flipping the hap on Intel-ME firmware?

Remote in this context means same lan subnet I think, which USUALLY is not an issue. It also depends on very old firmware nearly no one will be running. Just update your bios.

This is not usually a web accessible vulnerability.

Yeah; unless you were hit with rowhammer via browser jit or something as such perhaps (dunno)

 

[R-T-B]

I did. I have a few boards I need to update though, time is tricky to find:

ASRock Z370/Z390 Taichi (and some others, actively modding!) Firmware with Intel Management Engine Disabled, new method

This is a new thread to remove the clutter from my old one, which can be found here: https://www.techpowerup.com/forums/threads/asrock-z370-z390-taichi-and-some-others-actively-modding-firmware-with-intel-management-engine-disabled.243939/ This is for new builds utilizing a new technique which...

www.techpowerup.com

 

[Vya Domus]

About the RDRAND bug, it is completely beyond me why would anyone use that in the boot process of an OS. For one thing, this extension isn't present in most other CPUs out there so why use it now ? Actually, using RNG in the boost process of anything seems like a terrible idea in general and it's asking for a lot problems.

 

[TheoneandonlyMrK]

No problems here just using the stuff.

 

[R-T-B]

About the RDRAND bug, it is completely beyond me why would anyone use that in the boot process of an OS. For one thing, this extension isn't present in most other CPUs out there so why use it now ? Actually, using RNG in the boost process of anything seems like a terrible idea in general and it's asking for a lot problems.

Entropy is gathered in boot process in nearly all major OSes. Yes, RDRand is used if present on Windows. I imagine they work around the AMD Zen 2 series issue though.

 

[Vya Domus]

Entropy is gathered in boot process in nearly all major OSes. Yes, RDRand is used if present on Windows.

Why doesn't Windows crash at boot then ?

 

[biffzinker]

Why doesn't Windows crash at boot then ?

Maybe Microsoft issued a patch for Windows after the issue on Linux/Systemd came to light? TPM in the Ryzen SoC might be another reason?

 

[R-T-B]

Why doesn't Windows crash at boot then ?

It shouldn't even crash systemd really. As noted in the article, technically the value returned is a possible random number. Issue is that's ALL it returns. What causes hard freezes is when code expects a different result on a retry (which should happen in nearly all instances).

If I had to guess, I'd say they have a work around for this or entropy is silently compromised. Also Windows tends not to use KASLR, making it less essential to system stability.

 

[Vya Domus]

What causes hard freezes is when code expects a different result on a retry (which should happen in nearly all instances).

It should happen but this still sounds like terrible design. If you have something that takes some random bits as input and you're calling that function again already expecting it to give you something in particular, or, if certain outputs brake things, well, that just sort of defeats the purpose of doing that in the first place. RNG screwed up a lot of systems because of silly things like that.

Anyway it appears that Windows treats this in a sensible manner, at least to the level that it doesn't outright crashes, unlike the Linux kernel.

 

[R-T-B]

It should happen but this still sounds like terrible design. If you have something that takes some random bits as input and you're calling that function again already expecting it to give you something in particular, or, if certain outputs brake things, well, that just sort of defeats the purpose of doing that in the first place.

It's not that a few duplicate returns break it. It's using the RNG in systemd's case to generate ids that must be unique, ie not in use. Guess what happens when every return is the exact same? It's waiting forever for a "different" id that will never, ever come.

Anyway it appears that Windows treats this in a sensible manner

Depends. If it's silently using this as it's entropy pool, that could be even worse.

at least to the level that it doesn't outright crashes, unlike the Linux kernel.

Systemd simply hangs. The linux kernel is fine.