Re: [RFC PATCH] sbi: add hardware isolation abstraction framework

Yu-Chien Peter Lin
2026-04-05T07:24:14Z

Hi Raymond,

On 3/17/26 4:18 PM, Raymond Mao wrote:
> From: Raymond Mao <raymond.mao@riscstar.com>
>
> Introduce a system-level hardware isolation framework with a
> registration API and per-domain context tracking.
> This establishes an abstraction that allows multiple mechanisms to
> be composed while keeping core domain data structures independent
> of any single platform implementation.
>
> Signed-off-by: Raymond Mao <raymond.mao@riscstar.com>

Thank you for the RFC patch on the hardware isolation framework. I'm
currently
reworking our internal WorldGuard patches and plan to share them for
development
with Jim's WG QEMU simulation.

I wanted to offer some personal input based on my exploration of an
alternative
approach which might be useful as we gather community feedback.

The goal is to utilize WorldGuard for system-level protection in static
partitioning TEE scenarios (e.g., OP-TEE). To achieve this, we need to
work on two components:

1. RISC-V Worlds ISA Extension

The Worlds ISA extension [1] introduces per-hart World ID (WID)
management via
CSRs like `mlwid` and `mwiddeleg`. These concepts should integrate naturally
with OpenSBI's domain framework:

- Each domain can be assigned a `next_wid` (corresponding to `mlwid`)
- Each domain can be assigned a `next_widlist` (corresponding to
`mwiddeleg`)

When OpenSBI switches to a target domain, it assigns the domain's
`next_wid` to
`mlwid`, effectively enabling hardware-enforced physical address space
isolation
for that supervisor domain.

2. WorldGuard Checker Driver

The WG checker driver parses device-tree information and programs the
WorldGuard
checkers to create access control rules associating memory/device
regions with
allowed World IDs.
(We SiFive will also propose DT formats for this.)

Device Isolation Example:

deviceA: [0x10000000, 0x20000000) WID3
deviceB: [0x20000000, 0x30000000) WID0, WID3 (shared)
deviceC: [0x30000000, 0x40000000) WID0

Memory Partitioning Example:

Given a DRAM range `[0x8000_0000, 0x1_0000_0000)`, we can partition it
as follows:

| Mode | Main User | WID | Physical Address Range
|
|---------|-----------|----------|----------------------------------------------------------|
| M-mode | OpenSBI | 3 | [0x8000_0000, 0x800C_0000)
|
| SU-mode | Linux | 0, 1, 3 | [0x800C_0000, 0xC000_0000),
[0xC100_0000, 0x1_0000_0000) |
| SU-mode | OP-TEE | 1, 3 | [0xC000_0000, 0xC100_0000)
|

During a domain context switch, OpenSBI assigns the target domain's
`next_wid`
to `mlwid`. This ensures that the hart can only access memory regions
associated
with the active WID, providing hardware-enforced isolation.

One open question I'm exploring is whether to extend
`sbi_domain_memregion` with
WorldGuard-specific fields (flags, permissions, allowed WIDs) as bus checker
region descriptor for following considerations:
- WorldGuard checker slots will make use of TOR addressing mode, which
PMP does not
- WorldGuard slots do not have execute permission semantics, unlike PMP
- Reusing PMP-style flags directly may cause logic errors in functions like
`sbi_domain_check_addr()`

I haven't fully implemented this yet, so the design may change as I work
through
the details.

In addition to the RISC-V Worlds ISA specification, I'd like to share
resources/
found helpful for understanding WorldGuard and system-level protection:
- [1] RISC-V Worlds ISA Extension:

https://github.com/riscv/riscv-worlds/releases/download/riscv-isa-release-4ae2105-2026-01-09/riscv-privileged.pdf

- [2] RISC-V Secure System Partitioning with Worlds and TrustZone (v0.7.2):
https://github.com/MIPS/riscv-partitioning/releases/tag/v0.7.2

- [3] RISC-V Platform Security Model (v0.5):
https://github.com/riscv/riscv-security-model/releases/tag/v.05

- [4] RISC-V Implementing Application Processor TEEs (Whitepaper):

https://riscv.org/wp-content/uploads/2025/10/RISC-V-Implementing-Application-Processor-TEEs-REV-1.pdf

Again, these are just my quick notes and personal input for this milestone.
We should keep talking with the community to ensure our plan is on the right
direction.

Looking forward to collaborating on this!

Best regards,
Peter Lin