Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
China Security

Scientists Find Security Risk in RISC-V Open-Source Chip Architecture That China Hopes Can Help Sidestep US Sanctions (scmp.com) 39

An anonymous reader shares a report: A Chinese research team says it has uncovered a significant security flaw in processor design that could have a wide impact on China's booming domestic chip industry. China was relying on the structure of the world's largest open-source CPU architecture to build their own CPUs and bypass the US chip ban, and was paying attention to any weaknesses, they said. The issue was found in RISC-V, an open-source standard used in advanced chips and semiconductors. Compared with mainstream CPU structures -- such as X86 used by Intel and AMD --RISC-V offers free access and can be modified without restriction.

The flaw allows attackers to bypass the security protections of modern processors and operating systems without administrative rights, leading to the potential theft of protected sensitive information and breaches of personal privacy. The vulnerability was confirmed by the team of Professor Hu Wei at Northwestern Polytechnical University (NPU), a major defence research institute in Shaanxi province. The researchers are experienced in hardware design security, vulnerability detection and cryptographic application safety. It was first reported by the National Computer Network Emergency Response Technical Team/Coordination Centre of China (CNCERT) on April 24, and NPU gave further details in an official announcement on May 24.

This discussion has been archived. No new comments can be posted.

Scientists Find Security Risk in RISC-V Open-Source Chip Architecture That China Hopes Can Help Sidestep US Sanctions

Comments Filter:
  • Pessimal headline (Score:4, Informative)

    by Mononymous ( 6156676 ) on Wednesday June 05, 2024 @04:12PM (#64525647)

    The natural reading of the headline is that this flaw is good for China--but it's not.
    Write better.

    • Re:Pessimal headline (Score:4, Informative)

      by narcc ( 412956 ) on Wednesday June 05, 2024 @04:28PM (#64525689) Journal

      Did you read the article? It's somehow worse. Reading it will likely leave you less informed.

      • Burn. Nice.
      • by Gleenie ( 412916 )

        Yeah zero detail in the article. Is this one of the same class of speculative execution issues that are widely present in the hundreds of billions of x86 (and probably every other spec. ex.) processors already out there? Or an issue somehow absolutely unique to RISC-V? And given the miniscule adoption at the present time by comparison, presumably it can be fixed and everyone can move on (until the next time).

        From this article, we will never know.

      • by jmccue ( 834797 )
        You are suppose to read the articles here ? Learn something new every day!
    • Well we could have had the title as China Finds Security Risk in RISC-V Open-Source Chip Architecture. But then people wouldn't confuse it as "China failing", so of course have to delete China from the "found a bug" side, and add China to the "impacted by bug".

    • Why bad for China? It's open source, they can fix it in their next chip (or first chip for some of Chinese chips), unlike closed design chips like Intel which also have vulnerabilities discovered all the time, which China cannot fix, at the mercy of the manufacturer and potentially cannot buy replacements due to trade restrictions. With proprietary CPU they may not even be even able to find vulnerabilities what are kept secret by adversaries who do have access to the proprietary source. At least with open s
      • by HiThere ( 15173 )

        Fixing bugs in hardware is a bit harder than fixing bugs in software, but yeah. basically. It's bad for China because the bug needs to be fixed, and they're one of the main users of that hardware. (OTOH, as others have pointed out, it's not as if that's the only architecture with a bug.)

        I've no idea how serious the bug is, or how hard it is to fix, but hardware bugs are always more difficult to fix. Sometimes you can use firmware to route around them, but there's usually a performance penalty.

        So as one o

  • Pointless article. (Score:5, Interesting)

    by willy_me ( 212994 ) on Wednesday June 05, 2024 @04:33PM (#64525707)

    The first question I have - is this an issue with the RISC-V ISA or an issue with an implementation? If it is an issue with the ISA then it really is a big deal. It would require a new design and definitely sucks for any currently deployed hardware. If this is an issue with an implementation then this has little to do with RISC-V. Well, perhaps the ISA could evolve is such a way to make implementations naturally avoid such mistakes in the future. It is good that RISC-V designers are aware of these issues.

    But the article is useless and provides no real information. They do not make it clear that there is an issue with RISC-V. They just try to drive clicks by mentioning politics.

    • by gweihir ( 88907 )

      Yep, same here. The article is really useless.

      I guess a problem with the ISA is relatively unlikely and a problem with the implementation is relatively likely. Maybe the ISA is making the implementation flaw relatively likely if you do not know.

      • Yeah, it looks like another one of those sneaky cache side-channel attacks has popped up, this time potentially affecting some RISC-V CPU implementations. It's a tricky situation because chip designers are always looking for ways to boost performance, and techniques like speculative execution and cache prefetching are like legal performance-enhancing drugs for CPUs.

        The idea is to keep the CPU pipeline nice and full by speculatively executing instructions and preloading data into the caches before it's act
        • by gweihir ( 88907 )

          Well. I think in the end this needs to be solved on the software-side. Probably some compiler-flags to be put in when crossing protection domains or something like that. Makes writing secure code harder, but what else is new.

    • by hawk ( 1151 )

      >If it is an issue with the ISA then it really is a big deal

      As it turns out, the LNBS opcode actually stands for, "Let NSA Bypass Security."

      (It also seems to unmask HCF . . .)

  • by radoni ( 267396 ) on Wednesday June 05, 2024 @05:01PM (#64525771)

    There is no content in the article here. This is somehow even dumber than "and then this happened" headlines for clicks.

  • Holy bananas (Score:4, Interesting)

    by bill_mcgonigle ( 4333 ) * on Wednesday June 05, 2024 @05:15PM (#64525799) Homepage Journal

    Maybe this bug is what's going on:
    https://github.com/riscv-boom/... [github.com]

    • by haruchai ( 17472 )

      a week later & no one's even commented on it?

      • Remember this is a bug in an experimental academic RISC V core. While itâ(TM)s possible production cores have been synthesized from this, itâ(TM)s not a bug in the RISC V architecture.
    • It looks like it. The vulnerability is associated with a div instruction.
      • by ras ( 84108 )

        Unlikely.

        The bug report is about a floating point div (fdiv), not integer div. The bug mentions mentions a flag in "boom" is different to "strike". Boom is this implementation which calls itself the "Berkeley Out-of-Order Machine". Berkley University isn't based in China. I have in idea what "strike" is but given the bug report says fflags.NV is set to 1 in Spike. I guess it too must be a RISC-V implementation. fflags.nv is the likely what the RISC-V architecture manual calls fcsr.nv, which is the floa

  • I like to think of them not as security risks, but pathways to upgrades.

  • Chinese Hopes to Sidestep US Chip Sanctions Forestalled when Security Risk Discovered in Open-Source RISC-V Architecture
  • Here is the most primary source I have been able to find so far: https://mp.weixin.qq.com/s/ke8... [qq.com] Search on Baidu and use your favorite Translation tools. Happy hunting.
    • by st0nerhat ( 2540360 ) on Wednesday June 05, 2024 @09:33PM (#64526315)
      Translated excerpt: âoeIn the SonicBOOM processor, ALU (including addition), multiplication and division units use the same write port to access register files. In the case of write port contention, there is a fixed priority arbitration, where ALU has the highest priority and the division unit has the lowest priority. This means that due to port competition, the division instruction may be delayed by the younger multiplication or addition instruction, resulting in a difference in the execution time of the division instruction, resulting in a time-side channel.â
  • This is a garbage FUD piece. Processors don't do things like admin Rights. That's up to the operating system. RISC-V is a small device controller processor.
  • This article strikes me as incredibly dangerous.

    It suggests that this flaw (reportedly an issue with the ALU implemetation in the SonicBOOM CPU) is somehow associated with the RISC-V ISA (it is absolutely not) and that because of this, the US should consider curtailing RISC-V devices more generally. Such a reaction would be dangerous and utterly nonsensical. It is idiotic to even suggest it.

    What in the fuck are the editors of slashdot even doing?

  • There is one big problem with this story. If they found an exploit in China over this chip, they would never have let the new get out. What they would have done is use it as a backdoor into Western computer systems that use RISC-V chips. I think this is more likely FUD to shake confidence of the chips in the West and slow their development down because of designers looking for a problem that isn't there.

    I'll believe in it once it's been independently verified by US computer experts.

Too much of everything is just enough. -- Bob Wier

Working...