[HN Gopher] Faulty instructions in C910 RISC-V CPUs
___________________________________________________________________
Faulty instructions in C910 RISC-V CPUs
Author : johndoe0815
Score : 70 points
Date : 2024-08-07 17:33 UTC (5 days ago)
(HTM) web link (ghostwriteattack.com)
(TXT) w3m dump (ghostwriteattack.com)
| johndoe0815 wrote:
| The CISPA team in Saarbrucken (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_...
| str3wer wrote:
| i have a C906 running linux, how can i mitigate this
| vulnerability?
| camel-cdr wrote:
| 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
| taneliv wrote:
| 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 wrote:
| This almost won't impact CPU performance at all, because
| basically no software/packages use the XTheadVector custom
| extension.
| NovemberWhiskey wrote:
| 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.
| cpswan wrote:
| InfoQ coverage at https://www.infoq.com/news/2024/08/GhostWrite/
| sebazzz wrote:
| So this is a CPU implementation vulnerability, and not patchable
| through microcode. Are these CPUs used outside China?
| t-3 wrote:
| 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_...
| ljhsiung wrote:
| 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 wrote:
| 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 wrote:
| Most RISC-V processors are proprietory, the C910 is partially
| open source, excluding the draft vector extension
| implementation where the bug was located.
| dpeckett wrote:
| 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 wrote:
| Shoudln't this be the reason for customera to prefer 100%
| open processors?
| Arnavion wrote:
| 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.
| dwoxctbvgq wrote:
| 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.
| IshKebab wrote:
| 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.
| devit wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| duskwuff wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| vsetvli with x0 as destination is well defined by the spec.
| sylware wrote:
| You have to make mistakes to improve.
|
| This has been expected, and it will happen again.
___________________________________________________________________
(page generated 2024-08-12 23:00 UTC)