Trigger breakpoint exception action in debug mode about riscv-smmtt HOT 27 CLOSED

This seems not necessary. There are two scenarios:

1. M-mode is under debug
2. M-mode is not under debug but a specific supervisor domain is under debug

Scenarios 1 is everything goes - M-mode is the root of trust for the supervisor domains and the debugger has no restrictions.

For scenario 2, the triggers are context switched by the M-mode. When a supervisor domain executes, the M-mode will only have triggers corresponding to the active supervisor domain active. The external debugger cannot interfere here as a) when M-mode is doing the context switching (or any other work when in M-mode), the external debugger cannot interfere with the M-mode actions b) when a supervisor domain that does not have external debug allowed is executing the external debugger cannot interfere and setup any triggers not authorized by M-mode as external debug is blocked. For supervisor domains where external debug is allowed, the debug mode can setup triggers for that supervisor domain. However, those triggers will not be active when any other supervisor domain executes since the M-mode will context switch them.

from riscv-smmtt.

@AoteJin if the resolution @ved-rivos described above seems reasonable, then please ack so we can close this issue

from riscv-smmtt.

The only scenario of interest is 2.
The fact is that triggers are normally not part of context switch. Moreover, the hart could not program the trigger to enter debug mode. That is, the so-called context switch will be that security monitor scrubs all triggers and debugger reprogram triggers whenever it enters debug mode.
It turns out to be an awkward programming model.

from riscv-smmtt.

Note that trigger context switch is needed anyway because the triggers may be setup by the supervisor domain itself for self hosted debug. A word switch needs to switch the triggers of one supervisor domain with another. This would be optimized by the implementation - for example, if the neither the incoming or outgoing supervisor domains had triggers programmed by self hosted debug and neither had supervisor domain external debug enabled - then no switching of triggers is needed. This world switch will need to switch a bunch of other state such as the HPM CSRs, Control Transfer Records, all of the S* CSRs, x registers, f registers, v registers, etc.

And triggers are part of context switch. Even within a supervisor domain when self hosted debug is used and a process context switch occurs the triggers have to be switched when the process is switched.

The debugger does not need to "reprogram" the triggers - when the SD which is debug enabled is context switched in the triggers setup by the debugger would also be context switched into same state they were before.

from riscv-smmtt.

Please note that the hart cannot program trigger action to enter debug mode. That is, the hart cannot restore trigger context.

Trigger is machine mode resource in RISV-V. Self-host debugger leverages ebreak other than trigger.

from riscv-smmtt.

Please note that the hart cannot program trigger action to enter debug mode. That is, the hart cannot restore trigger context.

The triggers are programmable using the Trigger registers accessed using the Sdtrig CSRs by selecting the triggers using tselect. The Sdext CSRs are accessible from M-mode and Debug Mode. The scontext and hcontext are also accessible at lower privileges. The root domain security manager (RDSM) executes in machine mode. The RDSM is the entity that provides the SBI for the supervisor domains (SDs) to program triggers and is the entity that does world switching of the SD. The RDSM as part of the world switch will context switch the trigger registers.

from riscv-smmtt.

I think Aote is referring specifically to the tdata1.dmode bit, which can only be set to 1 from debug mode and, when set, causes all CSRs associated with that trigger to be writable only from debug mode. If the debugger sets that bit, the RDSM can no longer modify that trigger. Maybe the secure debug extension needs to alter this behavior to say that all modes above that enabled for debug can write to triggers with dmode=1?

from riscv-smmtt.

Yes, that was the expectation that when M-mode external debug is not enabled the dmode=1 triggers should not allowed. But that should not require restricting action=0 as that would disallow self-hosted debug in SDs.

from riscv-smmtt.

This will be a problem if we:

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

When do you execute the operation 2?
In secure debug, partition may only set the triggers within its memory regions (text, data, etc). This can be checked by RDSM.
Therefore, partition A should not set trigger to raise exception in address of partition B, right ?

from riscv-smmtt.

Summarizing the expected external debug security behaviors:

1. When medbgen is 0 and privilege is M
   a) dmode field of triggers is read-only zero.
   b) Abstract commands and haltreq from external debugger stay pending while privilege is M
   c) All trigger matching is suppressed
2. When SDEDBALW=0 and medbgen=0 and privilege is less than M
   a) Abstract commands and haltreq from external debugger stay pending.
3. When SDEDBALW=1 and medbgen=0 and privilege is less than M
   a) haltreq can transition to Debug Mode.
   b) Abstract commands and program buffer execution can access S and unprivileged CSRs.
   c) Access to M-mode CSRs other than the Sdtrig CSRs is not allowed.
   d) Memory accesses occur with either S or U privilege (as if MPRV or aamvirtual is 1 ).

from riscv-smmtt.

Thanks for the great summary!
The point is exactly with 3.c. Let’s say only partition A is debuggable by external debugger and the external debugger can legally set trigger to:

1. Enter debug mode in partition A
2. Exception in partition A
3. Enter debug mode in partition B
4. Exception in partition B

The case 1,2,4 can take effect when there is no trigger context switch.
However the case 1 is not able to be context switched by hart (case 3 won’t take any effect, so don’t care)
That’s why it is suggested to disallow debug mode set trigger to trap.

from riscv-smmtt.

I dont understand what the issue with 3.c. Orthogonal to context switching of triggers, when M-mode debug by external debugger is not allowed, external debugger should not be allowed to modify M-mode CSRs.

from riscv-smmtt.

In case #3, I think we want to say that M-mode can write to tdata* when tdata1.dmode=1. That ensures that the RDSM can switch the trigger state established by the S-mode debugger.

from riscv-smmtt.

The behavior for medbgen=0 is covered by 1a...The 3c is additive to 1a.

from riscv-smmtt.

Beeman suggested a change to 1a to instead of requiring dmode to be ROZ to allow M to write to dmode=1 triggers when medbgen is 0. Updating the summary:

1. When medbgen is 0 and privilege is M
   a) M-mode can read and write triggers - including triggers with dmode=1 - without restrictions
   b) Abstract commands and halt request from external debugger stay pending while privilege is M
   c) All trigger matching is suppressed (similar to how MIE or MTE would suppress them)
2. When SDEDBALW=0 and medbgen=0 and privilege is less than M
   a) Abstract commands and halt request from external debugger stay pending.
3. When SDEDBALW=1 and medbgen=0 and privilege is less than M
   a) Halt request can transition to Debug Mode.
   b) Abstract commands and program buffer execution can access S and unpriv. CSRs and other state at privilege mode less than M.
   c) Access to M-mode CSRs other than the Sdtrig CSRs is not allowed.
   d) Memory accesses occur with either S or U privilege (as if MPRV or aamvirtual is 1 ).

from riscv-smmtt.

so case 1 above needs to be specified in the broader secure ext. debug spec - (1a is the main behavior change).
case 2 and 3 are specific to supervisor domains and should be added to this spec

please correct if I am interpreting this incorrectly.

from riscv-smmtt.

Agree that 2 and 3 behavior should be specified as part of SEDBGALW description. Something like the following:

When M-mode external debug is enabled, all supervisor domains may also be debugged by an external debugger irrespective of the configuration held in SEDBGALW field of msdcfg register.

When M-mode external debug is disabled, whether execution at privilege modes less than M may be debugged by an external debugger depends on the configuration held in SEDBGALW field of msdcfg register.

• When SDEDBALW=0, external debug is disallowed. Abstract commands and halt request from the debug module are suppressed and stay pending.

• When SDEDBALW=1 then external debug of privilege modes less than M is allowed, and:
  ** A halt request may transition the hart to Debug Mode.
  ** Abstract commands and program buffer execution can access state of privilege modes less than M.
  ** Read and Write of Sdtrig CSRs is allowed.
  ** Debugger memory accesses occur with either S or U privilege (as if aamvirtual is 1 and MPP != M-mode).

from riscv-smmtt.

@ved-rivos I think we are finally on the same page and acknowledge the issue.

a) M-mode can read and write triggers - including triggers with dmode=1 - without restrictions

Beeman's suggestion is a valid approach. But it actually mandates all security monitor implementation to include trigger save/restore which leaves the responsibility to SM implementor , and it could be costly when trigger number scales up.

I would propose another solution. Instead of making dmode writable in machine mode by hart, the external debug security could prohibit debug mode to set trigger to raise exception.

The upsides are:

1. SM do not need to save/restore triggers if self-hosted debugger do not use trigger (with ebreak only)
2. It meets the the need of external debugger and self-hosted debugger with minimum effort
3. It more secure to prohibit than allow it. (M mode write to dmode/action to enter debug mode is a potential DoS attack surface)

from riscv-smmtt.

This will be a problem if we:

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

When do you execute the operation 2? In secure debug, partition may only set the triggers within its memory regions (text, data, etc). This can be checked by RDSM. Therefore, partition A should not set trigger to raise exception in address of partition B, right ?

Hi @gagachang, because the external debugger trusted to debug partition A is not necessarily trusted to debug partition B. And the malicious debugger might attack B with the debuggablity only granted to A. The RDSM could spot the vicious behavior by inspecting the all triggers during partition switch but it is totoally dependent on SW implementation and costly.

from riscv-smmtt.

SM do not need to save/restore triggers if self-hosted debugger do not use trigger (with ebreak only)

We should not preclude self-hosted debugger the ability to do data breakpoints or code breakpoints using triggers.

It meets the the need of external debugger and self-hosted debugger with minimum effort

The security monitors will need to context switch triggers as part of world switch. This is no more effort that switch any other CSRs such as HPMs.

It more secure to prohibit than allow it. (M mode write to dmode/action to enter debug mode is a potential DoS attack surface)

Please explain the DoS attack by M-mode switching triggers with dmode=1. The very act of allowing external debug for any SD is however a DoS attack because a debugger can enter debug mode from the debug allowed SD and then never resume blocking execution of all other SDs. Due to this, SMs will mostly not support running any SD with external debug allowed in production mode as a policy. The ability to debug a SD using external debug would have to be explicitly authorized as a policy to avoid such cases in production. But that is orthogonal.

from riscv-smmtt.

SM do not need to save/restore triggers if self-hosted debugger do not use trigger (with ebreak only)

We should not preclude self-hosted debugger the ability to do data breakpoints or code breakpoints using triggers.

It doesn't rule out the self-hosted debugger using trigger. It just points out a common practice that self-hosted debuggers do (e.g. ptrace uses ebreak for watchpoints and breakpoints). In this cases, trigger context switch can be saved.

It meets the the need of external debugger and self-hosted debugger with minimum effort

The security monitors will need to context switch triggers as part of world switch. This is no more effort that switch any other CSRs such as HPMs.

It is not generally true. HPM is only visible to sub-machine mode if it is enabled in mcounteren. Moreover, trigger context switch overhead could be 6x times of HPM (assuming 64 triggers).

It more secure to prohibit than allow it. (M mode write to dmode/action to enter debug mode is a potential DoS attack surface)

Please explain the DoS attack by M-mode switching triggers with dmode=1. The very act of allowing external debug for any SD is however a DoS attack because a debugger can enter debug mode from the debug allowed SD and then never resume blocking execution of all other SDs. Due to this, SMs will mostly not support running any SD with external debug allowed in production mode as a policy. The ability to debug a SD using external debug would have to be explicitly authorized as a policy to avoid such cases in production. But that is orthogonal.

Just like the statement "machine mode shall not enable debug for machine mode itself", the glitching could happen during trigger context switch or when self-hosted debugger uses trigger.

from riscv-smmtt.

It is not generally true. HPM is only visible to sub-machine mode if it is enabled in mcounteren. Moreover, trigger context switch overhead could be 6x times of HPM (assuming 64 triggers).

If HPM are made available to lower mode - and there is mcounteren and the Smcdeleg that were fast tracked for a reason - then they need to be switched. If they were not delegated then they dont need to be switched. Similarly triggers that are used for self hosted debug need to be switched and if a SD is under external debug the triggers need to be switched. If the SD is not under external debug or is not running a self hosted debugger then the triggers do not need to be switched. The cost of trigger context switch is not material - in production use there will be no SD with external debug enabled and running gdb in the OS is rare.

Just like the statement "machine mode shall not enable debug for machine mode itself", the glitching could happen during trigger context switch or when self-hosted debugger uses trigger.

Glitching can be done at various times and to affect variety of security states - for instance when programming MTT for memory isolation, when switching satp of the supervisor domain, or when switching GPRs of the supervisor domain. It is likely more productive to glitch settings of say satp or stvec than glitching triggers. Glicthing could be used to affect the privilege mode itself. But this is straying away from the topic and not relate to triggers.

from riscv-smmtt.

all - please see the PR #35 queued related to this issue.

from riscv-smmtt.

@ved-rivos I am confused with your statement. It is something like I was saying preventing debug mode to raise exception is 10 points better than making dmode writable by M-mode, while you arguing that it is only 5 points better.
But overall, if it is better and we should buy in the better one. If you don't think so, probably we could focus on the aspects that making dmode writable overweights?

from riscv-smmtt.

But overall, if it is better and we should buy in the better one. If you don't think so, probably we could focus on the aspects that making dmode writable overweights?

1. M-mode being able to write dmode=1 triggers is a functional requirement. Otherwise the M-mode will not be able to context switch between a external debug enabled SD and a non-external debug enabled SD. Consider two SDs - A and B - where A is external debug enabled and B is not. B has triggers established by self hosted debug and A has triggers established by external debug. When switching from B to A and vice versa, the RDSM needs to replace the triggers of A with B or B with A.
2. Given that 1 is functionally a requirement, additionally restricting breakpoint action to be written by an external debugger is not required.
3. On the argument that RDSM could save time switching the triggers e.g., leave the external debug triggers of A in place when running B, implies that when B actually requests a self hosted trigger the RDSM has to lazily go swap the external debuggers triggers. This adds complexity to RDSM since now it needs to remember which SD ran before B to do this action.
4. Lazy switching of triggers adds additional burdens to ensure that even if the triggers are suppressed that they dont have any side effects - e.g. if the hit bits update on due to A's triggers being left in place when B executes - even if it does not cause a debug mode entry or breakpoint, it is side channel because it lets the external debugger know - through the hit bits - which trigger was matched in B. The original described scenario "enable debug for partition A; set trigger to raise exception in address of partition B" - implies that matching triggers and updating hit bits is okay - as long as the debug mode entry is suppressed which is not true.

Considering external debugging of any SDs is not a production scenario and context switch time when a SD is under debug is not an issue and the ability to write dmode=1 is a MUST have requirement for functionally being able to switch triggers of a external debug enabled SD with those of a non external debug enabled SD, adding further ISA to restriction action=0 being not programable when done by debug mode is not necessary.

from riscv-smmtt.

@joxie @AoteJin please see PR #35
if it looks ok we can close this issue and merge that PR.

from riscv-smmtt.

closing since proposed spec change is included in PR #35 PTAL

from riscv-smmtt.