Debug access control for U-mode only domain

[AoteJin]

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 https://github.com/riscv/riscv-smmtt/issues/11#issuecomment-1918645811

[ved-rivos]

A supervisor domain should not be conflated with supervisor mode. In a M+U implementation, the supervisor domain only has U-mode. In a M+S+U implementation, it is M mode policy whether it allows execution in S-mode. The external debug control is for a Supervisor Domain - and not for S-Mode in a Supervisor Domain. When a Supervisor Domain is external debug allowed, all privilege modes in that Supervisor Domain are external debug allowed.

[AoteJin]

When a Supervisor Domain is external debug allowed, all privilege modes in that Supervisor Domain are external debug allowed.

Yes, this is exactly what I understood. But this will be an issue for TEE design like this: https://www.usenix.org/system/files/osdi21-feng.pdf

This TEE architecture has M+S+U privilege mode and creates U-mode only enclave to boost performance and improve memory utilization.

[ved-rivos]

But this will be an issue for TEE design like this

In such a design where RDSM only allows U-mode on a Supervisor Domain - that enclave is either external debug enabled or is not external debug enabled. Whether there is any execution in Supervisor Mode of that supervisor domain is not material. When running such U-mode only security domains there may or may not be page tables - if there are page tables setup for the U-mode then those page tables are managed by the RDSM and programmed into the satp. If there is no virtual memory used by those U-mode enclaves then RDSM sets the satp to Bare.

In the picture you listed you seem to imply that Domain 2 page tables will be in effect for Domain 1 execution. That is not correct. A page table, if used, has to be managed by the TCB of the domain 1 - and domain 2 is not in the TCB.

Could you elaborate on the specific issue?

[rsahita]

To add, the paper referenced above asserts that "The secure monitor maintains all the enclave page tables" on page 279 (memory isolation among enclaves). From the sw arch diagram, secure monitor runs in M-mode. If the M-mode RDSM is itself not under external debug, the U-mode SD can be ext-debug allowed without any impact to the enclave page tables managed by the RDSM.

[rsahita]

@AoteJin can i close this issue?

[rsahita]

closing this one - please re-open if required.