Releasing the RVA23 specification was a major milestone for the RISC-V community. While it provides an excellent baseline for deployment at scale, innovation continues to take place and we will see further extensions and profiles over the coming years.
Upcoming innovations fall into a couple of key areas
In this blog, we’ll look at these in more detail. We’ll also discuss Canonical and the wider community’s approach to supporting these extensions.
RISC-V has a number of mechanisms to address security. These include basic features such as memory protection, memory management, and privilege levels. But these are mostly about helping well behaved programs do the right thing. In modern computing, this is increasingly insufficient where the risk of malicious attacks keeps increasing. The good news is that there are also multiple levels of mechanisms to defend against this which are being actively developed. The first extension we’ll discuss is CFI, which was ratified by RISC-V international in 2024, while the other extensions we will cover are moving towards ratification in 2026 or 2027.
This is a lightweight, optional extension designed to protect against Return-Oriented Programming (ROP) and Call/Jump-Oriented Programming (COP/JOP) control flow attacks. Both of these mechanisms change the flow of the program and jump to unexpected places in the code. Clever use of these techniques can result in the ability to run arbitrary code using snippets (usually called “gadgets”) from elsewhere in the program binary.
CFI is composed of two independent extensions:
Both of these extensions govern control flow, in which typical attacks are about jumping to an unintended point in the code. They have been designed to prevent these kinds of attacks, and to maximize compatibility with existing RVA23 hardware, such that if the hardware implementation is not present, the instructions from these extensions will be ignored.
However, on pre-RVA23 hardware without the Zimop opcode support, the Zicfiss instructions will trap. While no-operation instructions (NOPs) are not ideal for performance and code size, this provides some flexibility where software can quickly adopt this (e.g. in compiler toolchains) and as soon as the hardware is available it will “just work”.
Here’s how they work:
RISC-V Control-Flow Integrity (CFI) – Ved Shanbhogue, Rivos & George Christou
AI/ML has been a massive growth area for RISC-V over the last few years, and continues to grow. The applications and use cases are just as diverse as those for processors, and ultimately most rely on a large amount of matrix math. The requirements for a small IoT endpoint will be different from a server, and correspondingly the right way to add these extensions varies too, depending on use case. RISC-V has three different methods to add matrix extensions:
I won’t explain them in detail here, but they provide different levels of scale for different applications (I’ve linked a video for a deeper dive at the end of the blog). From Canonical’s perspective, the more interesting thing is the impact for software and toolchains. The OS has to be aware of architectural state to handle context switches.
For VME, this is the same as standard vector extensions, so no additional state is needed, and no OS level changes are needed. IME and AME are more complex, requiring OS changes to support them. IME extends the Vector register file, and adds some additional registers for the results., while AME has a completely new register file. The OS needs to be aware of these registers during context switches.
In a previous blog about RISC-V custom instructions, we talked about using the sys_riscv_hwprobe() Linux system call to discover which extensions are implemented. This function will return a value to an application indicating whether a particular extension is supported. The same mechanism works for matrix instructions. What this means is that code libraries can be compiled with support for multiple implementation choices, and at runtime the software can choose the appropriate implementation.
It’s not surprising that architectures evolve over time. Applications change, new applications emerge, and the complexity of what it’s possible to implement in silicon changes too. Minor revisions to RISC-V ratified specification deliberately don’t include mandatory extensions. This provides longer term software stability while still allowing new innovations. There are two types of these optional extensions.
Development options are introduced as a precursor to becoming mandatory in a future profile and allow a softer landing. Expansion options are intended to remain optional and might target specific applications where the implementation cost is justified, but are too large to mandate for all users of a profile. Let’s now look at some of the new options in more detail.
This adds three development options and two expansion options. Of these five new extensions, there are three that are particularly relevant to Ubuntu.
This is about covering a small corner case during trap handling. If a second trap occurs while the first trap handler is still in a non-reentrant state, it can result in a system crash. This extension allows the machine mode or hypervisor mode to safely catch the second trap, improving system stability and reducing the risk of memory corruption.
This allows the Supervisor privilege level to manage and configure performance counter registers directly, without having to call to the machine mode firmware. For Linux utilities like “perf”, this provides a performance uplift when profiling code.
This extension allows for better profiling of branches. In particular it enables profile guided optimization (PGO), which is something we have talked about in the context of other architectures. PGO allows an iterative build process. The program is compiled with profiling options and an execution trace generated. This trace can be used for a subsequent build and informs the optimization process. PGO also requires upstream Linux kernel support for the kernel to expose the branch record buffers via “perf”. Patches are available, but haven’t been accepted upstream yet.
For Ubuntu to be able to make use of these extensions, as well as silicon support, we also need the toolchains (GCC, LLVM) to support them. Let’s look at each group in turn:
GCC and LLVM support these already today.
There are two approaches to targeting Matrix extensions.
These extensions are at different levels of maturity and need different levels of work. VME is relatively simple to support, while AME will need a lot of work. While waiting for ratification of the standard, it’s also possible there will be out-of-tree work done — for example Xuantie are working on a version of matrix extensions and have developed their own support in a private GCC branch.
Some of these features will be accessed by intrinsics or assembly CSRs rather than code generation per-se, however extensions like Ssctr directly interface to compiler profilers.
RVA23 established a great foundational baseline for RISC-V. For many years to come it will serve as the common platform which software builds against. And RVA23 binaries will run on newer silicon, so there’s no worry about loss in backwards compatibility. But as new features are made available, it’s useful to understand what the innovations are and how they can be used.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。