4 ms·

Faulty instructions in C910 RISC-V CPUs

77 points by johndoe0815 2y ago

johndoe0815 2y ago
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_c910_vulnerable/ https://www.theregister.com/2024/08/07/riscv_business_thead_...
- str3wer 2y ago
  i have a C906 running linux, how can i mitigate this vulnerability?
  - camel-cdr 2y ago
    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 https://github.com/T-head-Semi/openc906 (doesn't include XTheadVector extension) [1] https://github.com/camel-cdr/rvv-d1 https://github.com/camel-cdr/rvv-d1
  - taneliv 2y ago
    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.
    - camel-cdr 2y ago
      This almost won't impact CPU performance at all, because basically no software/packages use the XTheadVector custom extension.
  - NovemberWhiskey 2y ago
    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.
sebazzz 2y ago
So this is a CPU implementation vulnerability, and not patchable through microcode. Are these CPUs used outside China?
- t-3 2y ago
  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_c910_vulnerable/ https://www.theregister.com/2024/08/07/riscv_business_thead_...
cpswan 2y ago
InfoQ coverage at https://www.infoq.com/news/2024/08/GhostWrite/ https://www.infoq.com/news/2024/08/GhostWrite/
ljhsiung 2y ago
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).
- dpeckett 2y ago
  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).
  - camel-cdr 2y ago
    Most RISC-V processors are proprietory, the C910 is partially open source, excluding the draft vector extension implementation where the bug was located.
    - dpeckett 2y ago
      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.
    - miohtama 2y ago
      Shoudln’t this be the reason for customera to prefer 100% open processors?
devit 2y ago
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.
- akira2501 2y ago
  > 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.
  - dpeckett 2y ago
    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.
  - devit 2y ago
    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.
Arch485 2y ago
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.
sitkack 2y ago
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_thead_c910_riscv_chips_blow_away_all/ https://old.reddit.com/r/RISCV/comments/1emhhzs/alibabas_the...
- duskwuff 2y ago
  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.
  - dzaima 2y ago
    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)
djmips 2y ago
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.
ruslan 2y ago
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.
- tsukikage 2y ago
  vsetvli with x0 as destination is well defined by the spec.
  - dzaima 2y ago
    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.
sylware 2y ago
You have to make mistakes to improve. This has been expected, and it will happen again.

77 points by johndoe0815 2y ago

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_c910_vulnerable/ https://www.theregister.com/2024/08/07/riscv_business_thead_...

str3wer 2y ago
i have a C906 running linux, how can i mitigate this vulnerability?
- camel-cdr 2y ago
  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 https://github.com/T-head-Semi/openc906 (doesn't include XTheadVector extension) [1] https://github.com/camel-cdr/rvv-d1 https://github.com/camel-cdr/rvv-d1
- taneliv 2y ago
  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.
  - camel-cdr 2y ago
    This almost won't impact CPU performance at all, because basically no software/packages use the XTheadVector custom extension.
- NovemberWhiskey 2y ago
  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.

sebazzz 2y ago

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

t-3 2y ago
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_c910_vulnerable/ https://www.theregister.com/2024/08/07/riscv_business_thead_...

cpswan 2y ago

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

ljhsiung 2y ago

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

dpeckett 2y ago
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).
- camel-cdr 2y ago
  Most RISC-V processors are proprietory, the C910 is partially open source, excluding the draft vector extension implementation where the bug was located.
  - dpeckett 2y ago
    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.
  - miohtama 2y ago
    Shoudln’t this be the reason for customera to prefer 100% open processors?

devit 2y ago

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.

akira2501 2y ago
> 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.
- dpeckett 2y ago
  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.
- devit 2y ago
  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.

Arch485 2y ago

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.

sitkack 2y ago

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_thead_c910_riscv_chips_blow_away_all/ https://old.reddit.com/r/RISCV/comments/1emhhzs/alibabas_the...

duskwuff 2y ago
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.
- dzaima 2y ago
  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)

djmips 2y ago

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.

ruslan 2y ago

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.

tsukikage 2y ago
vsetvli with x0 as destination is well defined by the spec.
- dzaima 2y ago
  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.

sylware 2y ago

You have to make mistakes to improve. This has been expected, and it will happen again.