Does RDSM need to maintain one MTT structure per domain? Or the domains share one global MTT structure?

I can imagine that if supervisor domains share all the physical memory, there would be one MTT structure per supervisor domain. Although there would be additional overhead for RDSM to save/restore memory contents during domain switching to avoid data leakage.

So it seems that more common policy is allocating mutually exclusive memory regions to supervisor domains.
(e.g., 2GB memory, first 1GB is allocated to SD0 and remaining 1GB is allocated to SD1.)
Obviously, one MTT structure per domain is feasible.
But I am wondering if one global MTT structure is enough in this policy.
However it needs MTT entries to have SDID field to tag which domain owns that memory region, am I correct?

The trigger action 0 (Raise a breakpoint exception) is legal in debug mode. This will be a problem if we:

1. enable debug for partition A
2. set trigger to raise exception in address of partition B

The adversary could take advantage of breakpoint exception action to tamper partition B, since the exception behavior is not subject to current debug control knob.

Proposal to mitigate:
Disallow the trigger being set to action 0, in debug mode.

Other actions seem fine. Even if the adversary leaves footprint in trigger, the action will not take effect.

Previously we did not mandate the implementation details of debug control logic. The logic might be far away from the hart (e.g. inside Debug Module) depending on implementation.  This choice of design will lead to TOCTOU issue. For example, an incoming haltreq passes the check logic, but the hart changes to a undebuggable privilege mode when haltreq arrives hart.

Mitigation: the spec shall explicitly mandate implementations to guarantee no privilege change between debug request check and serving the debug request by hart.

Similar, the same rule should be mandated for trigger that privilege must not change during debug control check and trigger firing/matching when trigger action is configured to enter Debug Mode.

External trigger missing M/S/VS/VU enable bits in tmexttrigger CSR. The debugger with S-mode privilege might affect M-mode by enabling an external trigger and letting it fire in M-mode code to achieve attack (e.g. DoS, side channel).
Mitigation: Add per privilege enable bit in tmexttrigger like other triggers.

External trigger inputs might have resource belongs to M-mode (e.g. interrupts or performance counter etc.). A S-mode debugger might snoop the behavior the M-mode by enable those external trigger.
Mitigation: Since M-Mode is enabled by RoT, external triggers should be enabled by RoT as well .

Just as discussed in external debug TG meeting on Jan 30th, it is agreed to move the ISA part to smmtt spec. File the issue to track progress.

I think we need a chapter in smmtt to fit in and rephrase this part of external debug security draft
https://github.com/joxie/riscv-external-debug-security/blob/dev/chapter2.adoc

The current proposal has only a knob in CSR to enable debuggability for supervisor mode. It will result in privilege escalation if a domain has only U-mode application (e.g. PENGLAI TEE architecture). This choice of U-mode only domain might reduce overhead of context switch (without save/restore S-mode context).

There are tow direction to mitigate:

1. In addition to S mode knob, add another U mode knob.
2. Mandate that the SW has to add a thin layer of S mode runtime to enable self-hosted debug

Originally posted by @AoteJin in #11 (comment)

I think the intent of Smmtt is that data that passes PMP / MTT checks should be shared between supervisor domains based on:

To support IO/memory sharing, a hart/device may perform accesses to memory exclusively accessible to its supervisor domain, and to memory shared globally with all supervisor domains or other specific supervisor domains. Memory sharing between supervisor domains is achieved by simply making the physical memory region accessible to the supervisor domains via the MTT structure.

Later in the document it states that:

Data and instructions cached for one supervisor domain shall not be accessible to another supervisor domain, so the SDID (along with the other execution context identifiers such as ASID, VMID, shall factor into the data and instruction caches tags to enforce isolation.

I read this as memory shared globally with all supervisor domains but cached under one supervisor domain cannot be accessed by another supervisor domain (even though PMP and MTT checks passed). Is this understanding correct and what's the rationale?

Document Supervisor domains interaction for RISC-V Capacity and Bandwidth Controller QoS Register Interface (CBQRI)

Add PMP as an option for supervisor domain isolation:

• Add PMP as a mode in table 3.1
• When PMP mode is used, then MTT is not required and PMP is used instead for physical memory isolation between domains
• When PMP mode is used, the SDID CSR can still be used to identify the currently active supervisor domain

This allows systems based on PMP or MTT as the underlying physical memory isolation mechanism to implement and support supervisor domains in a consistent way across the RVI architecture.

Root supervisor domain manager should be able to control which supervisor domains are allowed to be debugged.

Initial debug configuration for a supervisor domain is expected to be derived from some configuration/manifest (and optionally reported as part of attestation) -- and then enforced by the root domain manager via this debug control.

Debug state of the Root supervisor domain manager itself is expected to be gated by the platform RoT (and also optionally reported as part of attestation).

As a person interested in this specification (as a developer once involved TEE), I'd like to prepare for it and found something not obvious from the documentation.

Considering from the CSR existence (16 CSRs allocated tentatively) and being dependent from Smmtt, Svpams looks like an extension. However, the documentation does not refer Svpams as an extension.

If you have any free time, clarifying whether Svpams is an extension would be helpful.

Hi,

When I read section 6.4 Machine Interrupt registers (mip and mie), it says:

The Smsdia extension introduces the machine supervisor domain external interrupt-pending (MSDEIP
- bit 32) field in mip and the machine supervisor domain external interrupt-enable (MSDEIE - bit 32)
field in mie.

The mip and mie in Priv. Spec. is MXLEN, which is MXLEN=32 on RV32, which only has bit 0 ~ bit 31.
AIA extends them to have high-half miph and mieh.

Does it mean that Smsdia has dependency on AIA ?

According to Priv. Spec.: Machine Trap Delegation Registers (medeleg and mideleg):

mideleg holds trap delegation bits for individual interrupts, with the layout of bits matching those
in the mip register (i.e., STIP interrupt delegation control is located in bit 5).

Per discussion in #34.
We may not want to delegate MSDEI to less privilege mode.
If this is true, it's helpful to explicitly mention that mideleg[32] should be hard-wired to 0 if CPU supports Smsdia.

Some TEE OSes may have a requirement to toggle the interrupt enable bit from the REE. For instance, OPTEE calls spin_lock_xsave() to disable both FIQ and IRQ during some critical sections. It seems like the riscv porting effort has to upgrade this operation to a sbi-call even with smsdia in SMMTT. This is because msdeie is an m-mode register, and SDEIE is only available in mie, which means delegation of this type of interrupt to s-mode is impossible. This is a good security choice as s-mode domain should not interfere with interrupts belonging to others. Every thing related to inter-domain managements should be done by the RDSM. However, this may increase the latency or complexity to do interrupt management when the relationship between some domains are not symmetric (Linux + OPTEE).

To achieve the improved latency without sacrificing security. Should we consider adding following 2 changes?

1. Make SDEIE visible in sie so delegation works.
2. Add an m-mode MAXLEN CSR msdeideleg E.g. to selectively determine if any of a supervisor domain external interrupts are able to be delegated.

Interrupts for an inactive s-mode domain only get delegated into the hart if mie.SDEIE is set, and the bit representing the s-mode domain in msdeie and msdeideleg is set. Interrupts for an inactive domain where msdeie is true but msdeideleg is not set still trigger a m-mode interrupt.

This type of delegation does not mean the running s-mode domain should process interrupts from an inactive s-file domain. Instead, this delegation works as a mask-able notification for the running s-mode domain.

1. An implementation may not implement all SDID domains, especially for larger SDIDLEN. Therefore, should we allow SDID to be WARL?

2. When mttp.MODE == 0, the spec currently states:

In this case, the remaining fields (SDID, MTTPPN) in mttp must be set to zeros, else generate a fault.

Can hardware force the other values to 0 when mttp.MODE== Bare such that a fault doesn't need to be generated?

I would like to know why MTTPPN[1:0] should always read as 0.
Please explain it to me, thanks.

For systems supporting multiple supervisor domains, add AIA extension along the lines of:

• mseip and mseie CSR
• mip.msdeip = |(mseip[] & mseie[])

allowing M-mode to arbitrate interrupts across multiple supervisor domains, analogous to corresponding registers allowing a hypervisor/OS to arbitrate interrupts across multiple guests.

Supporting an interrupt model along the following lines:

• (Logically) separate APLIC and IMSIC for each supervisor domain
• Each follow current AIA specification (no change to AIA spec; no change to programming model for S-mode software)
• M-mode manages access control to each (logical) instance of APLIC/IMSIC - for example PMP/IOPMP
• M-mode can arbitrate across S-mode interrupts and domains (context switch, mute, whatever)
• M-mode can delegate interrupts for the currently active supervisor domain

Refer also to discussion with Ved.

In a virtualised system the same mechanism can be used for multiple domains at HV level.

Hi,

A couple of questions relating to Chapter 7 (Smsdia) please.

1
With respect to the Supervisor Domain External Interrupt (SDEI); The current text does not contain where in the priority order this is expected to be seen - am I right in thinking that since this is a machine-mode only interrupt which cannot be delegated, it comes before SEI?

Multiple simultaneous interrupts destined for different privilege modes are handled in decreasing order of
destined privilege mode. Multiple simultaneous interrupts destined for the same privilege mode are handled in the
following decreasing priority order: MEI, MSI, MTI, SDEI, SEI, SSI, STI, LCOFI.

2

3
https://github.com/riscv/riscv-smmtt/blob/3b03fb0a0ee88fc077006cb8e77d3ae3ffe67093/chapter7.adoc?plain=1#L40C1-L55C5
The "Supervisor Domain Interrupt Assignment" diagram references an SD-0 APLIC/IMSIC, but msdcfg does not allow 0 to be used as a selection for an IMSIC/APLIC. Is this intentional?

4

As always, the state-enable CSRs do not affect the accessibility of any state when in M-mode, only in less privileged modes.

Am I right in thinking that the intended behaviour in all modes including M is actually to be the same as if there is no IMSIC connected (e.g. sireg access while siselect is in the IMSIC range raises an illegal instruction exception)?

When siselect is a number in a reserved range (currently 0x00–0x2F, 0x40–0x6F, or a number above 0xFF not designated for custom use), or in the range 0x70–0xFF when there is no IMSIC, attempts to access sireg should preferably raise an illegal instruction exception (unless executing in a virtual machine, covered in the next section).

Thanks! :)

Selina

If Smmtt also supports M-mode only or M/U mode systems, where S-mode is absent, adding some description or diagrams for those use cases is helpful to people.

Originally posted by @gagachang in #3 (comment)

Alternately could be controlled via the msdcfg.SDEDBGALW for both ext debug and trace