Faulty instructions in C910 RISC-V CPUs | Hacker News Reader

Faulty instructions in C910 RISC-V CPUs

ghostwriteattack.com

77 pointsjohndoe081534 comments

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 verifying them is quite costly.

The (equally) hard part with CPU design is funnily enough not in creating the design, but the verification. (That's kinda one small reason why I think CoPilot-esque tools haven't permeated the hardware design space very much).

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 build their own OS's. It'll be contributing features and bugfixes to existing designs (and designing custom extensions).

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.

Shoudln’t this be the reason for customera to prefer 100% open processors?

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.

May I ask what circuit simulator game? I've attempted something similar with my very limited and hobby level hardware knowledge in Virtual Circuit Board and I learned that it would take me much longer than a weekend, heh.

Turing Complete - https://store.steampowered.com/app/1444480/Turing_Complete/

I also made my own assembler as part of learning the ISA and put it at https://github.com/Arnavion/riscv . You can see a screenshot and video of the CPU in action there.

The game's campaign walks you through creating a simple 8-bit CPU and then a larger CPU similar to old ARM. But then it also has a sandbox to do whatever, and you can use whatever design you want to solve the puzzles intended for the original two CPUs.

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.

Yes, it would be disastrous if a widely-used chip had a bug in its division opcode.

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

It would be disastrous if a widely-used chip had a bug in a lock prefix that allowed crafted untrusted binaries to soft-brick the whole machine.

https://en.wikipedia.org/wiki/Pentium_F00F_bug

I'm not even mentioning the weirdnesses from the eight-bit era. We all know those chips were heroic efforts to get anything done given transistor budgets, and error checking was simply not possible. The point is, even mature proprietary companies have had severe hardware bugs for longer than many here have been around, even if you discount stuff like spectre and meltdown.

The same used to be said of open source competition to Oracle's database. An open source DATABASE? Unthinkable! First off it would be prima facie insecure, and secondly, it would be a toy that could never compete on important things like performance!

My takeaway from this is that the existence of RISCVuzz will make future verification much easier. Just run your prototype (or even an emulation of it) against a known good array of implementations.

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?

Most likely you have the mitigation already in place, that is disabeling the XTheadVector extension. The regular distributions don't enable it, since it's a non standard incompatible vendor extension based on a draft spec.

When I wanted to benchmark their implementation last year I patched a kernel to enable it, and needed to consult the open source part of the core [0] to figure out that they placed the enable CSR bit in a different location than the final ratified spec. [1]

[0] https://github.com/T-head-Semi/openc906 (doesn't include XTheadVector extension)

[1] https://github.com/camel-cdr/rvv-d1

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.

Do you let people run arbitrary code on your linux box? If not, you don't have anything to worry about, as far as I can see.

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.

https://old.reddit.com/r/RISCV/comments/1emhhzs/alibabas_the...

I don't think that's accurate. These vector instructions are defined (by the vendor) and were intended to be accessible; the problem is that they have unexpected and insecure behavior.

The instruction in question doesn't map to any instruction in neither RVV0.7.1/xtheadvector, nor RVV1.0. Disassemblers don't disassemble it, and assemblers don't have any mnemonic for it (the 'vse128.v' used by the authors is essentially arbitrary afaict; and even if it weren't, there's zero reason to think that C910 had any intention of supporting 128-bit elements)

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 backdoor it seems surprising that it would not be authenticated with a secret key, but maybe they are very incompetent.

> 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.

It seems it's an invalid encoding if I understand the article correctly.

There seems to be some debugging utility in such a mechanism, e.g. you could use it to run CPU tests, benchmarks or debug code in userspace of a stock OS and then directly communicate with serial port MMIO without needing to pollute the CPU state with a system call or change the kernel to directly map the MMIO into userspace.

This looks very much like someone adding performance instructions and only paying attention to performance at the expense of security.

Likely an oversight rather than malicious intent.

So this is a CPU implementation vulnerability, and not patchable through microcode. Are these CPUs used outside China?

I was going to say I've only ever seen it in the specs of hobbyist-level devices and I doubt it's being used anywhere on scale even inside China, but El Reg says:

> The C910-based TH1520 SoC is used by French cloud Scaleway.

https://www.theregister.com/2024/08/07/riscv_business_thead_...

Has anybody noticed that malformed vsetvli instruction is using x0 register as destination (returning vl to be used by app) which in most RISCs is hard-wired zero. Very unlikely that writing to zero reg was not tested during design verification process as it's one of the obvious corner cases.

vsetvli with x0 as destination is well defined by the spec.

There's the mild note that the behavior of the 'x0, x0' form changed between RVV0.7.1 and 1.0 - on 0.7.1 it sets VL=VLMAX, while on 1.0 it inherits the previous VL. That said, the 0.7.1 behavior is still useful, and improper behavior would certainly be caught by basic testing, never mind the users who have had chips with it for a while.

InfoQ coverage at https://www.infoq.com/news/2024/08/GhostWrite/

You have to make mistakes to improve.

This has been expected, and it will happen again.

Reply on news.ycombinator.com