[RFC PATCH] sbi: add hardware isolation abstraction framework

[Raymond Mao]

Hi Peter,

On Sun, Apr 5, 2026 at 3:24 AM Yu-Chien Peter Lin <peter.lin at sifive.com> wrote:
>
> Hi Raymond,
>
> On 3/17/26 4:18 PM, Raymond Mao wrote:
> > From: Raymond Mao <raymond.mao at 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 at 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!
>

Thanks for the detailed feedback and the WG/Worlds context — very helpful.

The proposed HWISO is meant to be a generic framework for isolation
management across domain lifecycle phases (boot, domain_init, domain
exit/enter). The intent is to keep this layer mechanism‑agnostic, and
have specific technologies (like WG/Worlds) plug in as one of the
registered mechanisms.

>From your description, WG fits well: a WG mechanism can parse its own
DT binding, keep per‑domain context (next_wid/next_widlist, checker
config), and program hardware on domain enter/exit. This avoids
forcing WG into PMP semantics or sbi_domain_memregion.

So for this phase I plan to keep the HWISO abstraction minimal and
mechanism-driven. When you share the WG DT format and implementation,
we can integrate it as another registered mechanism under HWISO
without refactoring the framework itself. If we discover we need
multi‑instance support or richer matching at the framework level, we
can evolve it then.

Looking forward to continuing the discussion.

Thanks and regards,
Raymond

> Best regards,
> Peter Lin