Evolution of the RISC-V ISA. What next after RVA23?

Introduction

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

• Security related extensions, such as Control Flow Integrity (CFI).
• Performance related extensions such as Matrix
• Minor specification updates, such as RVA23.1

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.

Security 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.

Control Flow Integrity

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:

• Zicfilp
• Zicfiss

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: 

• The first extension (Zicfilp) creates landing pads. If the program branches to a location that isn’t a landing pad, it will trap. This means an attacker can’t branch to an arbitrary location that isn’t an explicit branch target.

• The second (Zicfiss) is similar, but about protecting function returns. A typical attack would try and overwrite the stack, so when a program returns, it branches to a different location from the originally saved one. This extension adds a shadow stack. When a function call is made, the return address is stored in both the normal stack and shadow stack. On returning from that function the values are compared, and  a mismatch will result in a trap. In that case, the execution is stopped before the attack can start.

RISC-V Control-Flow Integrity (CFI) – Ved Shanbhogue, Rivos & George Christou

Matrix extensions

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:

• Integrated Matrix Extension (IME)
• Vector Matrix Extension (VME)
• Attached Matrix Extension (AME)

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.

Profile updates 

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 option
• Expansion option

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. 

RVA23.1

This adds three development options and two expansion options. Of these five new extensions, there are three that are particularly relevant to Ubuntu.

• Double trap Handling (Ssdbltrap)
• Supervisor Counter Delegation (Sscfg)
• Control Transfer Records (Ssctr)

Double Trap Handling

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.

Supervisor Counter Delegation

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. 

Control Transfer Records

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. 

Toolchain support

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:

Control flow integrity

GCC and LLVM support these already today. 

Matrix

There are two approaches to targeting Matrix extensions. 

• One is to use compiler intrinsics (essentially writing assembly-like code). 
• Harder is to have the compiler automatically target matrix instructions. 

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.

RVA23.1

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. 

Conclusion

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.

Further reading

• RISC-V CFI specification
• Announcement of RVA23.1 and RVB23.1 public review
• For a deeper dive into IME, VME, and AME, SiFive published a video:  SiFive 2nd Generation Intelligence Technology Explainer