Live data from Hacker News

Faulty instructions in C910 RISC-V CPUs

ghostwriteattack.com

21–30 of 35 posts

Re: Faulty instructions in C910 RISC-V CPUs

#21
post #15

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.

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.

Re: Faulty instructions in C910 RISC-V CPUs

#22
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?

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.

Re: Faulty instructions in C910 RISC-V CPUs

#24
post #18

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.

Re: Faulty instructions in C910 RISC-V CPUs

#25
post #7

Earlier quoted context omitted.

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.

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

Re: Faulty instructions in C910 RISC-V CPUs

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

Re: Faulty instructions in C910 RISC-V CPUs

#27
post #26

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.

Re: Faulty instructions in C910 RISC-V CPUs

#29
post #18

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)

Re: Faulty instructions in C910 RISC-V CPUs

#30
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…

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…

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.
Post reply on HN