‘Sinkclose’ Flaw in Hundreds of Millions of AMD Chips Allows Deep, Virtually Unfixable Infections

refalo , 2 hours ago

need boot capabilities in order to “exploit” this

only with broken Secure Boot implementations

already patched in EPYC microcode

a nothingburger released suspiciously a day after Intel breaks news of being sued by their own shareholders (techpowerup.com/…/intel-faces-shareholder-lawsuit…)

ShortN0te , 4 hours ago

What a shitty clickbait title.

virtually all AMD chips dating back to 2006, or possibly even earlier.

Title could be shorter and more precise while still having the same deeming message.

Bitrot , 2 hours ago

It’s not just the title that is poorly written. The entire thing is written like “the sky is falling because memory chips and big computer stuff has a broken”.

JAWNEHBOY , 4 hours ago

Archive version: web.archive.org/web/…/amd-chip-sinkclose-flaw/

velox_vulnus , 5 hours ago

This is why we need open-source hardware. Close-sourced designs are plagued with so many issues, and I bet some of these flaws have still not been reported.

mesamunefire , 5 hours ago

Agreed. Im hoping to see more RISC-V processors make it to commercial hardware. We are starting to see it with some experimental single board computers and laptops, but they are still much too slow. But its getting there!

milkv.io/mars#buy might be a good place to start, although im looking for the spec sheet…

Ive been on the lookout for a “good enough” server with RISC-V. Would love to play around with it.

vikingtons , 5 hours ago

RISC-V ISA isn’t magically exempt from vulnerabilities. You can still be hit at a microcode level.

phoronix.com/…/GhostWrite-Vulnerability-RISC-V

For AMD, I’m wondering if OpenSIL can help prevent similar, deep system firmware vulnerabilities from lingering cross numerous product generations.

mesamunefire , 1 hour ago

It would improve the number of eyes if you had full specs. You can arguably identify exploits and bugs much faster.

I also just want RISC-V :)

vikingtons , 1 hour ago

I also want to see RV develop to a point where it can compete with incumbents but this isn’t a hardware vulnerability. The issue here lies with AGESA, AMD will be moving to OpenSIL hopefully around 2026.

Furthermore, RISC-V is an Open ISA but that doesn’t necessarily mean products based on this remain open.

deafboy , 5 hours ago

"GhostWrite is the result of an architectural flaw, a hardware bug in the XuanTie C910 and C920 CPU. These are only two of many RISC-V CPUs, but they are widely used for a variety of applications. According to the research team, vulnerable devices include:

Scaleway Elastic Metal RV1, bare-metal C910 cloud instances

• Milk-V Pioneer, 64-core desktop/server
• Lichee Cluster 4A, compute cluster
• Lichee Book 4A, laptop
• Lichee Console 4A, tiny laptop
• Lichee Pocket 4A, gaming console
• Sipeed Lichee Pi 4A, single-board computer (SBC)
• Milk-V Meles, SBC
• BeagleV-Ahead, SBC"

tomshardware.com/…/ghostwrite-vulnerability-explo…

vikingtons , 5 hours ago

Isn’t this specific to AGESA rather than the hardware itself?

Dudewitbow , 3 hours ago

they would still be vulnerable. if you only care about security, you would be running a FPGA because anything fully secure would be slow, because speculative execution is inherently full of security flaws, and also the major reason why CPUs have any semblance of performance.

ShepherdPie , 3 hours ago

That’s a tall order when a fab costs tens of billions of dollars to operate. Somebody needs to make a lot of dough out of the process.

CasualTee , 1 hour ago

I don’t think that’s the issue. As said in the article, the researchers found the flaw by reading the architecture documentation. So the flaw is in the design of the API the operating system uses to configure the CPU and related resources. This API is public (though not open source) as to allow operating system vendors to do their job. It usually comes with examples and pseudo code on how some operations work. Here is an example (PDF).

Knowing how this feature is actually implemented in hardware (if the hardware was open source) would not have helped much. I would argue you are one level too low to properly understand the consequences of the implementation.

By the vague description in the article it actually looks like a meltdown or specter like issue where some code gets executed with the inappropriate privileges. Such issues are inherent to complex designs and no amount of open-source will save you there. We need a cultural and maybe a paradigm shift on how we design CPU to fully address those issues.