Notes on RISC-V Support and Security Implications
May 20th, 2023
Updated: January 18th, 2024
Chris Rohlf
RISC-V (pronounced “risk five”) is an open standard Instruction Set Architecture (ISA) developed in the open by a large number of contributors.
It has a permissive license model for both open and closed source implementations of the standard. The RISC-V documentation, discussions, and
standards are public and can be found on Github.
DeRiscing General Computing From Export Controls
The October 7th (2022) rule published by BIS placed new unprecedented restrictions on the export of certain semiconductors and related fabrication materials, supplies, and software to China.
“Certain Advanced Computing and Semiconductor Manufacturing Items; Supercomputer and Semiconductor End Use; Entity List Modification”
Bureau of Industry and Security
These export control rules are written to target performance metrics of semiconductors (e.g. TFLOPS/TOPS), and not specific chip architectures by name, or general description. Although the October
7th rule likely targeted high end chips designed and sold for AI/ML applications they likely created a lot of uncertainty for the future of general high performance computing in China. It’s worth
noting that even modern general purpose computing cores come equipped with advanced matrix multiplication instructions for edge AI applications. What was ‘high performance computing’ reserved for
data centers just 5 years ago now sits idle in your pocket.
One might want to consider what a v2 of these export controls might look like. Could they target semiconductors meant for general purpose computing? And if so, at what point in the supply chain would
be the most likely choke point? Despite Asia’s dominance in the fabrication and manufacturing of semiconductors, the most popular general purpose computing ISA's and designs are the intellectural property of western companies.
In many cases these can be licensed for a fee. This business model presents an excellent opportunity for some, and a difficult choice for others. One potential way to avoid this is to invest heavily in a
modern alternative that is not subject to such licensing requirements.
RISC-V meets some of those needs, at least for the ISA. The ISA is only one such component in a modern SoC but it's an extremely important one. Designing a new ISA from scratch
without the input of industry contributors is an enormous undertaking. As we discuss below, specifying the ISA is just the first step of many. A proprietary ISA requires a large investment in software infrastructure
in foundational components needed to support it. Developing these from scratch, and not contributing changes to the existing software infrastructure needed to power their use, is extremely unlikely to succeed.
Chinese tech companies are likely to invest heavily in RISC-V going forward as a
way to de-risk their dependence on western designs and intellectual property.
Open Source RISC-V
An open source ISA with active development is good, but it is largely useless until someone implements support for fundamental software
components such as compilers, linkers, kernels, C libraries, debuggers, JITs etc. There is already wide support for the RISC-V ISA from
mainstream open source software including LLVM, GCC, Linux Kernel, and Android among many others. But RISC-V standards are a rapidly moving
target and as new designs emerge this software support will need to greatly expand.
Almost 1 year before the October 7th rule was announced Alibaba open sourced the design of four of its RISC-V cores. These cores target a
range of workloads from embedded microcontrollers to cloud servers. The open source documentation and code for these cores can be found here.
Future investment in RISC-V will likely include a similar open source contribution, either complete open sourcing of chip designs, or smaller
upstream contributions to various existing software projects to support the software stack that will run on top of these new chips. A large
set of foundational components must first be modified/built to support this architecture before the platform is suitable for user applications:
- LLVM and GCC Compiler Infrastructure
- Code generation
- Optimization pipelines
- Just In Time (JIT) compilation support
- Javascript JIT components in web browsers
- Android Dalvik/ART JIT
- Linux Kernel BPF
- Foundational C Libraries (libc, math etc)
- Common functions (memcpy, memset etc) optimized for RISC-V
- Machine optimized floating point, matrix multiplication, and vector operations
- Toolchains
- GNU Binutils
- Debuggers (GDB, LLDB)
- Disassemblers, decompilers
RISC-V Security
Over the last decade many general security and memory safety exploit mitigation technologies migrated from software to hardware
(Intel CET, ARM MTE, ARM BTI, ARM Trustzone etc). These hardware implementations are significantly more performant than software at
protecting forward and backward edge control flow transfers, enforcing privilege levels, and more. Many similar concepts have found
their way into the RISC-V standards. Studying these specifications will be key to understanding how secure, or insecure, a RISC-V
implementation / based device is.
- Control Flow Integrity
- “To enforce backward edge control flow integrity, the extension introduces a shadow stack. To enforce forward edge control flow integrity, the extension introduces labeled landing pad instructions.”
- This standard is still under development but will heavily influence exploitation strategies against memory safety vulnerabilities in RISC-V targets.
- If a RISC-V implementer deploys these correctly they may significantly raise the bar for exploitation relative to proprietary ISA’s. But if they choose to not implement them, and the implementation is not available in a widely adopted compiler toolchain, then software vulnerabilities running on these systems would be easily exploitable.
- https://github.com/riscv/riscv-cfi
- JIT’d Language Targets
- This standard is attempting to make RISC-V ISA more friendly to programming languages that are typically JIT’d from an interpreted bytecode (Python, Ruby, Javascript etc). These extensions would primarily serve to make JIT development easier and produce more performant code for common operations and design patterns such as NaN-Boxing, and dynamic typing.
- Could result in different instruction density and security relevant constructs for programs written in these languages.
- https://github.com/riscv/riscv-j-extension
- Cryptography Extension
- “This repository is used to develop standardization proposals for scalar and vector cryptographic instruction set extensions for the RISC-V architecture.”
- Cryptographic instruction extensions make heavily used mathematical operations in common cryptographic schemes much more performant (e.g. vectorizing AES-CTR/GCM operations so they may be performed many times per-second over data streams).
- This standard could also influence how security critical operations such as secure boot are implemented.
- https://github.com/riscv/riscv-crypto
- Virtual Memory Extension
- This standard is focusing on virtual memory specifics such as address translation, cacheability, etc.
- This standard is important for understanding any side channel risks inherent to the architecture as demonstrated on other popular ISA’s over the last several years (e.g. Spectre, Meltdown etc).
- https://github.com/riscv/virtual-memory
- Multi Zone Privilege Security Model
When a RISC-V implementer publishes their product as compliant with a specific RISC-V standard it creates an opportunity to diff that
product's specific implementation against the standard. Any deviations from the standard will be worth investigating for security
vulnerabilities or backdoors. This is not an operation you can easily perform against a proprietary ISA.
RISC-V has the potential to bring new and exciting security capabilities to semiconductors from low end embedded devices all the way
up to edge computing, high performance cloud computing, and even ‘supercomputers’.
Given the open nature of RISC-V standards I expect the ecosystem of RISC-V implementations to suffer many of the same issues the Android
ecosystem has. Some implementations will be incomplete, or deviate from the specification in undocumented ways to support specific workloads
they were designed for. These differences will create security vulnerabilities for consumers as devices based on RISC-V begin to be deployed
at scale. The diversity of the RISC-V ecosystem may present the biggest security challenges in the years ahead. But it also has the potential
to create opportunities for security protections to be designed, implemented, and deployed at scale in rapid time.