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

[Yu-Chien Peter Lin <peter.lin@sifive.com>]

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

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi