The CISPA team in Saarbrücken (Germany) discovered a number of significant security vulnerabilities in T-Head C906/906/910 CPU cores. More details at https://www.theregister.com/2024/08/07/riscv_business_thead_...
i have a C906 running linux, how can i mitigate this vulnerability?
From the article:
> No, software updates or patches cannot fix this vulnerability because it is a hardware bug. The only mitigation is to disable the vector extension in the CPU, which unfortunately impacts the CPU’s performance.
i have a C906 running linux, how can i mitigate this vulnerability?
From the article: > No, software updates or patches cannot fix this vulnerability because it is a hardware bug. The only mitigation is to disable the vector extension in the CPU, which unfortunately impacts the CPU’s performance.
This almost won't impact CPU performance at all, because basically no software/packages use the XTheadVector custom extension.
I've definitely had this thought about this sort of openness that RISC-V inherently promotes. Sure, anybody can make a RISC-V CPU, but who really has the capabilities to verify them? There's a reason the ARM model has succeeded-- that is, providing totally off-the-shelf IP with pre-verified cores (because of their own large verif team). The logical end of RISC-V is that we have custom cores literally everywhere, but…
Is it the logical end that we have custom cores everywhere? Yes RISC-V is open and relatively straightforward to implement (coincidentally I did just that over the weekend in a circuit simulator game), but I can also see economies of scale making it so that a few vendors end up making cores that are good enough for all use cases between them and end up dominating the market. A few low-powered 32E cores, a few desktop-grade 64GCBV... alphabet soup (or more likely, hanzi lamian) cores, and a few in between would seem to be enough.
Isn't this the Cathedral vs Bazaar debate all over again? All designs have flaws, but at-least with something like the C910 you can open a PR to fix it going forwards. Sure the first revisions of a new design will be buggy, but over time with iteration and continuous improvement they'll only get better. I don't think too many folks will be designing new RISC-V cores from scratch, in the same way that very few people…
Most RISC-V processors are proprietory, the C910 is partially open source, excluding the draft vector extension implementation where the bug was located.
Yeh it's a shame T-HEAD didn't release the source for the draft vector extension. Admittedly they had their reasons.
While it might be true, and remain true for high-end designs, we're really seeing a proliferation of mid-to-low end RISC-V SoCs out of china based on open source IP.
Could this a debugging instruction that was mistakenly left enabled in production or possibly even an intentional backdoor?
Most modern ISAs like RISC-V provide no way of directly accessing physical memory regardless of privilege (you have to either disable paging or setup page tables to point to the physical memory you want), so it seems unlikely that one could accidentally implement one.
In case of an intentional backdoor it seems surprising that it would not be authenticated with a secret key, but maybe they are very incompetent.
This is such a severe bug it almost feels like a supply chain attack/back door of some sort. Is that a likely scenario here? I saw another comment saying that these CPUs are used in Scaleway's cloud, so it's certainly a legtitimate attack vector.
Disclaimer: I don't build CPUs, and as such I don't know what I'm talking about.
Could this a debugging instruction that was mistakenly left enabled in production or possibly even an intentional backdoor? Most modern ISAs like RISC-V provide no way of directly accessing physical memory regardless of privilege (you have to either disable paging or setup page tables to point to the physical memory you want), so it seems unlikely that one could accidentally implement one. In case of an intentional b…
> Could this a debugging instruction
Highly unlikely. It's an actual vector instruction that you would otherwise use. The problem is it bypasses page table protections when invoked with memory operands. There is no debugging utility in this mechanism.
This is a consequence of not specifying that an encoding should lead to a fault. It isn't that the instruction is faulty, it is that the instruction doesn't exist and still triggers an action. Yes it is semantics, but a distinction worth noting.
Could this a debugging instruction that was mistakenly left enabled in production or possibly even an intentional backdoor? Most modern ISAs like RISC-V provide no way of directly accessing physical memory regardless of privilege (you have to either disable paging or setup page tables to point to the physical memory you want), so it seems unlikely that one could accidentally implement one. In case of an intentional b…
> Could this a debugging instruction Highly unlikely. It's an actual vector instruction that you would otherwise use. The problem is it bypasses page table protections when invoked with memory operands. There is no debugging utility in this mechanism.
Secondly the extension is explicitly marked as experimental and is disabled on pretty much all kernel builds.
Some of these platforms are incredibly janky atm, so I'm not at all surprised that something like this could slip through.
The real surprise is scaleway rushing them into production.
I've definitely had this thought about this sort of openness that RISC-V inherently promotes. Sure, anybody can make a RISC-V CPU, but who really has the capabilities to verify them? There's a reason the ARM model has succeeded-- that is, providing totally off-the-shelf IP with pre-verified cores (because of their own large verif team). The logical end of RISC-V is that we have custom cores literally everywhere, but…
Companies taping out chips have the capability to verify them. The open source verification systems and tests are definitely like only 5% of a proper verification, but there are commercial tests and models that are much better.
I think the real question is not how you verify a CPU - we know how to do that. It's how you know how well a CPU has been verified. This is all based on reputation currently.