Live data from Hacker News

Faulty instructions in C910 RISC-V CPUs

ghostwriteattack.com

1–10 of 35 posts

Re: Faulty instructions in C910 RISC-V CPUs

#5
post #4

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

Re: Faulty instructions in C910 RISC-V CPUs

#6
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).

Re: Faulty instructions in C910 RISC-V CPUs

#7
post #6

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…

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

Re: Faulty instructions in C910 RISC-V CPUs

#8

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?

Re: Faulty instructions in C910 RISC-V CPUs

#9
post #7
post #6

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…

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.

Re: Faulty instructions in C910 RISC-V CPUs

#10
post #8

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

Post reply on HN