[RFC PATCH v5 0/4] Add Smsdid and Smmpt supervisor domain protection

[Huamao Wu]

Hi Rahul,

One design point on the SDID assignment.

mpt_state_setup() currently allocates one SDID per SBI domain, at domain
registration time, taking the first free bit:

    for (sdid = 0; sdid < ctrl->max_domains; sdid++)
            if (bitmap_test(ctrl->sdid_bitmap, sdid))
                    break;
    if (sdid >= ctrl->max_domains)
            return SBI_ENOSPC;

SDIDLEN is implementation defined and may be as small as 1, i.e. two SDIDs in
total. OpenSBI domains are also used for purposes unrelated to MPT (per-hart
PMP partitioning, per-domain MPXY channels, IPI grouping), so a platform can
easily have more domains than SDIDs while only one or two of them actually
need a separate MPT. On such hardware the current binding turns a
configuration choice into a boot failure: SBI_ENOSPC propagates from
mpt_state_setup() to sbi_domain_finalize() and sbi_init() ends up calling
sbi_hart_hang(). Note that sbi_mpt_init() already treats missing Smmpt
hardware as non-fatal (returns SBI_ENODEV and sbi_hart_init() ignores it), so
"not enough SDIDs" is handled more strictly than "no Smmpt at all".

Proposal: make the SDID assignment opt-in per domain instead of implicit for
every domain.

 - Add an optional u32 property "sdid" to the opensbi,domain,instance node.
   When absent, the domain runs under SDID 0, i.e. under the root domain's
   MPT, and relies on PMP for its own isolation.
 - The MPT of SDID N is built from the memregions of the domain that owns N.
   SDID 0 is always owned by the root domain and its tree is built once.
   Domains aliasing to an already-owned SDID do not get a tree of their own.
 - An explicit "sdid" must be < 2^SDIDLEN and unique across domains.
 - A domain aliasing to SDID N must still program mmpt explicitly on
   activation. Right now sbi_mpt_hart_activate_for_domain() returns 0 when
   !sd->valid and sbi_mpt_hart_deactivate() is empty, so a hart switched away
   from an MPT-backed domain keeps the previous SDID in mmpt and would run
   under the previous domain's MPT. Today every domain has a valid tree so
   this is not reachable, but with opt-in assignment it becomes the normal
   path.
 - When SDIDLEN is smaller than the number of explicitly requested SDIDs,
   report it and continue with the domains that fit rather than hanging.

This keeps the common case (PMP-only platform, Smmpt capable hart) working
without any MPT memory, and lets a platform with SDIDLEN=1 run root plus one
protected domain.

The assumption behind defaulting to SDID 0 is that PMP/ePMP remains the
primary memory protection for domains without their own SDID; Smmpt is
layered on top (sbi_hart_protection_configure() applies the TYPE_MEMORY
protection and the TYPE_ID protections independently, so the effective
permission of such a domain is its PMP entry set intersected with the SDID 0
MPT). If the intent is for Smmpt to replace PMP on some platforms, then
sharing SDID 0 is not safe and this proposal does not apply.

Regards,
Huamao Wu