WorldGuard: A Hardware-Level Isolation Specification for the RISC-V Architecture (Proposal Stage)

Source information

• Source: RISC-V Developer Community
• Author / ID: zevorn
• Original: https://ruyisdk.cn/t/topic/1275
• Original publication date: 2025-08-30

Summary

This article explains the RISC-V WorldGuard proposal, centering on the core concepts of World, WID, TEE, ISA extensions, WG markers, and WG checkers, and describes its design goals for system-level hardware isolation.

This content is suitable for archiving under topics such as RISC-V security extensions, hardware isolation, TEE, and platform security models.

Archive note

This is an index for a published off-site article; the full text has been imported below.

Body

As RISC-V has been widely adopted in embedded systems, cloud computing, and other fields, the need for hardware-level security isolation has become increasingly prominent.

Based on the WorldGuard RVIA specification (version v0.4), this article systematically explains the design philosophy, core architecture, and implementation mechanisms of WorldGuard technology.

WorldGuard builds an independent “World” execution context through physical-address access constraints, uses the hardware world identifier (WID) to isolate multiple Worlds, and combines RISC-V ISA extensions with non-ISA hardware components to form a complete access-control system.

The specification defines three levels of ISA extension support (no extension, Smwg extension, Smwgd/Sswg extension) and general WG checker hardware modules, and clarifies the transaction handling flow and the response mechanism for privilege violations.

This technology can be configured by a trusted execution environment (TEE) at system boot time, and supports isolation for 2–8 Worlds, providing a low-cost, high-security hardware isolation solution for RISC-V platforms.

QEMU upstream has recently started supporting the RISC-V WorldGuard extension (proposal). Taking that opportunity, let’s take a detailed look at it.

Unlike PMP/PMA, WorldGuard (WG) mainly provides system-level isolation across Harts and devices. The following compares the core differences:

Below is a detailed explanation of the WorldGuard extension.

Click me to listen to the ima podcast: https://ima.qq.com/share/#/ai-chat/XiJ055pOp

Introduction

Technical background

RISC-V architecture, with its open source nature, extensibility, and flexibility, has become an important standard in processor design.

However, as application scenarios grow more complex, the need for security isolation between different execution contexts has become more urgent — for example, when a trusted system and an untrusted application run on the same hardware platform, the untrusted application must be prevented from accessing trusted resources out of bounds.

Traditional software-level isolation approaches (such as virtual memory and sandboxes) suffer from large performance overheads and dependence on the security of the software stack, whereas hardware-level isolation can directly constrain resource access through hardware mechanisms, providing higher security and efficiency.

WorldGuard positioning

WorldGuard (WG for short) is a hardware isolation proposal for the RISC-V architecture and is currently at the initial stage of RVIA (RISC-V International Association) standardization.

Its core goal is to build isolated execution units (“Worlds”) in hardware through physical-address access control, enabling resource isolation between different Worlds while balancing hardware cost and configuration flexibility.

Compared with other hardware isolation technologies such as RISC-V PMP, WorldGuard supports global permission management across multiple Worlds, and its configuration is typically completed at system boot time, making it more suitable for scenarios that require strong isolation stability.

Document scope

This article is based on WorldGuard RVIA specification v0.4 and focuses on the core concepts, ISA extension design, non-ISA hardware components, and transaction handling flow, as a reference for subsequent implementation and standardization work.

Core WorldGuard concepts and overall architecture

Core definitions

World

A World is the basic isolation unit in WorldGuard. It is defined as an execution context that contains agents and resources:

• Agents: hardware entities that can initiate physical-address transactions, including harts (processor cores) and peripheral devices. Each agent context belongs to exactly one World at a time;

• Resources: hardware entities that can respond to physical-address transactions, including memory and peripherals. They are uniquely identified by system physical address and can be shared across multiple Worlds (with independent permissions in each World).

Hardware World Identifier (WID)

Each World is identified by a unique WID. The platform supports a maximum of NWorlds WIDs. Considering hardware cost, the specification recommends choosing NWorlds in the range 2–8 (requiring 1–3 bits of binary encoding); the exact number is determined by the platform design.

Trusted Execution Environment (TEE)

A TEE is the trusted component responsible for World configuration. It typically completes the assignment of agents and resources to Worlds during system boot or reset, and once the configuration takes effect, it cannot be modified dynamically unless the system is reset (the current specification does not treat “runtime dynamic configuration” as a design goal).

Overall architecture

The WorldGuard architecture consists of two core parts:

1. RISC-V ISA extensions: add control and status registers (CSRs) to associate hart privilege modes with WIDs and support World switching across different privilege modes;

2. Non-ISA hardware components: include WG markers (which attach WIDs to agent transactions) and WG checkers (which validate transaction permissions) to provide hardware-level physical-address access checks.

The two parts work together to form a complete “transaction marking - permission checking - result response” flow:

1. An agent initiates a physical-address transaction, and the WG marker attaches the current World’s WID to the transaction;

2. As the transaction propagates across the bus, the WG checker verifies the target resource’s permission for that WID;

3. If the permission check passes, the transaction completes normally; if it violates permissions, the transaction is terminated or modified and an error is reported according to the rules.

RISC-V ISA WorldGuard extension

To support flexible World management by harts, the specification defines three levels of ISA extension support, with the features and dependencies of each level shown in the table below.

Three-level ISA extension support system

Key CSR design

CSRs (Control and Status Registers) are the core of the ISA extension and are used to store WID configuration and delegation information. The key CSRs defined by the specification are listed below.

Special rules and compatibility design

Memory access tagging rules

All memory accesses (including instruction fetches and implicit accesses such as page-table walks) must be tagged with the current World’s WID, and instruction fetch is treated as a “read” in permission checks — this is because buses usually do not distinguish instruction fetches from data reads, so a unified permission-checking policy is required.

WID modification restrictions

• A privilege mode cannot modify its own WID; only higher-privilege modes may modify the WID of lower-privilege modes (for example, M-mode modifying [H] S-mode, or [H] S-mode modifying U-mode);

• The WID of M-mode is set by the external environment and does not change during reset; different harts may use different WIDs in M-mode.

Virtual memory compatibility

If the system supports demand-paged virtual memory, the address translation cache (such as the TLB) must cache translation results separately for each WID to avoid conflicts between different Worlds. The specification recommends flushing the address translation cache when mlwid, mwiddeleg, or slwid is written to ensure that the configuration takes effect.

Non-ISA WorldGuard hardware components

The non-ISA hardware components are the execution layer for WorldGuard permission checks, including WG markers and WG checkers. Among them, the “general WG checker” is the core module defined by the specification and supports flexible address ranges and permission settings.

General design principles for components

• Customization support: WG markers can be customized for specific device agents (for example, peripheral-specific marker logic), and WG checkers can be customized for specific resources (for example, different checking strategies for memory and peripherals) to reduce hardware cost;

• Configuration safety: dynamic configuration state (such as checker rules) must be initialized to a “safe state” on reset (for example, all permissions disabled), and should support locking after initialization (to prevent unauthorized modification). Locked state can only be cleared by system reset.

General WG checker design

The core function of the general WG checker is to monitor a fixed physical address range and configure each World’s access permissions through programmable “rule slots”. It is suitable for scenarios that need flexible permission management, such as memory-region isolation.

Basic functionality and address range

• The address range monitored by the checker is usually a naturally aligned NAPOT region (Naturally Aligned Power-Of-Two), which is convenient for hardware implementation;

• The checker’s address range may be larger than the actual address range of the downstream device (for example, if the device address range is 0x1000_0000–0x2FFF_FFFF, the checker range may be set to 0x0_0000_0000–0x3_FFFF_FFFF); addresses not routed to the device do not affect the checking logic.

Memory-mapped configuration registers

The checker’s configuration registers are mapped to an independent physical address region and are accessible only to trusted software. They support 32-bit reads and writes (and wider accesses for better configuration efficiency). The key configuration registers are listed below.

Rule slot format and configuration

Each rule slot occupies 32 bytes and contains address, permission, and configuration information, as shown below.

The cfg register is the core of rule configuration. Its key bit fields are defined as follows:

• A [1:0] (bits 1:0): address range type, supporting OFF (disabled), TOR (top of range), NA4 (4-byte aligned), and NAPOT (power-of-two aligned, ≥8 bytes);
• ER (bit 8) / EW (bit 9): whether to report a bus error on read/write permission violations;
• IR (bit 10) / IW (bit 11): whether to trigger an interrupt on read/write permission violations;
• L (bit 31): lock bit; once set, the slot configuration cannot be modified (unlock requires reset).

Error reporting mechanism

The checker records privilege violations through the errcause and erraddr registers. The core logic is as follows:

• erraddr: stores the violating physical address, shifted right by 2 (addr [65:2]), ensuring that RV32 systems can store 34-bit addresses;

• errcause: records violation details, including the WID that caused the violation (bits 7:0), access type (bit 8 = read, bit 9 = write), whether a bus error is generated (bit 62), and whether an interrupt is generated (bit 63);

• Reporting limit: new violations update the registers only when both the bus-error bit (be) and the interrupt bit (ip) in errcause are 0; software must clear these two bits before error reporting can resume.

Transaction handling and privilege-violation response

Normal transaction flow

When an agent (hart/device) initiates a physical-address transaction, the flow is as follows:

1. The WG marker attaches the current World’s WID to the transaction;

2. The transaction propagates across the bus, and any WG checker it passes through validates the target address against that WID;

3. If at least one rule allows the access (permissions are accretive, meaning overlapping rules are treated as an “allow” intersection), the transaction completes normally;

4. If all rules deny the access, a privilege-violation handler is triggered.

Privilege-violation response strategy

When a privilege violation occurs, the checker must ensure that World isolation is not broken. The response strategy has two parts:

1. Transaction handling:

• Write operations: ignore the write to the target resource and do not modify the resource data;

• Read operations: return “harmless data” unrelated to the target resource (usually 0) to avoid leaking trusted information.

2. Error reporting:

• If the rule configuration sets the ER/EW bits, return an error response on the bus;

• If the rule configuration sets the IR/IW bits, trigger an interrupt and update the errcause/erraddr registers;

• In some scenarios (for example, when the initiating agent cannot be directly notified of the error), the violation is reported only through another agent (such as a management hart).

Version history and future outlook

Version iterations

WorldGuard RVIA specification v0.4 is the latest version, and its revision history is as follows:

• Version 0.1 (2022-10-31): initial draft, based on WorldGuard HAS Specification 1.1;

• Version 0.2 (2022-11-20): second draft, refined and intended for donation to RVIA;

• Version 0.3-draft (2022-11-22): third draft in development;

• Version 0.3 (2023-04-03): formally donated to RVIA;

• Version 0.4 (2023-04-27): clarified checker operation logic, added support for non-32-bit accesses, and removed the optionality requirement for NAPOT.

Future challenges and directions

The current specification is still in its early stage. Key issues that remain to be solved include:

1. Dynamic configuration support: the current specification does not support runtime changes to World configuration; a low-cost dynamic configuration mechanism needs to be explored to accommodate scenarios such as virtualization;

2. Multi-platform compatibility: the specification allows platform-specific implementations (such as bus WID propagation methods), so compatibility test standards need to be defined to ensure interoperability across hardware from different vendors;

3. Performance optimization: permission checks may introduce bus latency, so techniques such as parallel checking and cache optimization need to be studied to reduce overhead.

Conclusion

WorldGuard technology provides a hardware-level security isolation solution for the RISC-V architecture through a three-layer design of “World isolation + WID tagging + hardware checking.”

Its ISA extensions support flexible privilege-mode/WID association, its non-ISA hardware components provide efficient permission checking, and the overall design balances hardware cost and security.

Although the current specification is still in the early stages of standardization, its core architecture already has clear application scenarios (such as embedded security and cloud-native isolation), providing an important reference for future security enhancements on RISC-V platforms.

In the future, as issues such as dynamic configuration and compatibility testing are resolved, WorldGuard is expected to become one of the core security standards of the RISC-V architecture.

References

[1] WorldGuard RVIA Specification v0.4, 2023. [2] RISC-V Privileged Specification, https://riscv.org/technical/specifications/.