Debug control for supervisor domains

[rsahita]

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).

[rsahita]

The proposed change to support this is to add a "debugAllowed" control bit into the Smsdid CSR

[rsahita]

10/3 - this topic is discussing external debug (not self-hosted debug).

Base Threat model:

• Debug is disabled by default and has to be opted-into via explicit authorization at some point in the system reset sequence.
• [Any keys derived for attestation/sealing takes the external debug state (enabled/not-enabled) into account]
• If debug is disabled, then it cannot be enabled without a system reset (typically through the RoT).
• Corollary - debug module is in the TCB to establish debug state before root domain manager is initialized.

(Open) Expand to include Tracing.

(Open) Performance monitoring - self hosted is ok/contained within supervisor domain. PMU events controlled by external event monitors should be treated same as debug. (Exists) Root domain manager is able to disable hart instruction counters to prevent leakage of info across SDs.

Separate controls or one control for external debug/trace/perf "opt-in/allowed/capability"? Some SD use cases may need separate allowed controls/policies. for CC, one control is deemed enough (separate works also). does not need to be an atomic control since the capability is not effective until the SD is entered.

[gokhankaplayan]

We have a new TG for this issue. The proposed charter aims to target both Smmtt and WorldGuard: https://github.com/riscv-admin/external-debug-security/blob/main/CHARTER.md

You can find the proposal draft here (it will be migrated to RISC-V git repo): https://github.com/joxie/riscv-debug-security/blob/main/spec/Secure%20Debug%20Proposal.md

According to proposed draft, mdbgsec CSR is a machine mode CSR, which control external debug and trace enables per privilege level. It can be re-configured during context switch between supervisor domains. Does it matches with your aim here, @rsahita ?

To prevent M-mode TCB, there is an plan to add lock feature as discussed here: https://github.com/joxie/riscv-debug-security/issues/9

[rsahita]

thanks - some opens - Where would the opt-in policy per Supervisor domain be stored - does that become a software convention? and to confirm - the debug controls for the Supervisor domain (HS/S(V)/U(V) are activated when the supervisor domain is entered via MRET?

[rsahita]

11/28 - "debugAllowed" per supervisor-domain can be firmware state managed (and will need to be part of the attestation state of the SD). However M-mode does not have control over external debug state machine - so the input into this FSM has to come via a configuration bit that feeds into the external debug state machine.

Resolution: We propose to add this configuration bits per SD in the already proposed M-mode CSR: "msdcfg" CSR (which currently also holds Smsdia configuration for SDs).

[rsahita]

@gokhankaplayan please see discussion from today above.

[gokhankaplayan]

Let me give the answer with respect to the proposed secure debug draft:

thanks - some opens - Where would the opt-in policy per Supervisor domain be stored - does that become a software convention?

It is not stored per supervisor domain. mdbgsec CSR has opt-in policy per privilege level (U/VU/VS/HS/M). The current draft relies on context switch between domains. The debug policy for each supervisor domains is known by M-mode software.

and to confirm - the debug controls for the Supervisor domain (HS/S(V)/U(V) are activated when the supervisor domain is entered via MRET?

Yes, they will be activated when entered via MRET.

Resolution: We propose to add this configuration bits per SD in the already proposed M-mode CSR: "msdcfg" CSR (which currently also holds Smsdia configuration for SDs).

Why do you think opt-in debug policy per SD is required in a CSR? In other words, why is context switch not good enough? This topic has discussed here: https://github.com/joxie/riscv-debug-security/issues/9. But, we could not elaborate about the reasoning. If you give us more reasoning, per ID opt-in policy can be also added to mdbgsec CSR?

[joxie]

@rsahita the current external debug security draft provides one register (M-mode) for root domain to control external debug for every SD, that assumes existence of a manifest for each domain with debug policies and other configurations. The manifest needs to be attested and stored in root domain memory and root domain manager will need to reprogram mdbgesc with debug policy when switching supervisor domain.

If my understanding to above proposal is correct it is to add an index to msdcfg to select which policy to use, similar to SDICN, correct? Looks like you also assume that the policy comes from an external hardware component that outside of the hart?

If that's the case then we can make it work.

We may need to simplify the proposal to just differentiate M and sub-M though.

[ved-rivos]

The proposal is as follows:

The msdcfg CSR contains the sdedbgen bit that controls whether the current scheduled SD is external debug enabled. This bit is context switched (along with rest of the msdcfg) per SD. The medbgen is a external debug enable for the M-mode driven by the debug module and is established by the RoT. When privilege is M, the medbgen gates the haltreq_i from the debug module and if is 0 prevents the hart from entering debug mode. When privilege is less than M, the OR of the sdedbgen and medbgen gates the haltreq_i from the debug module and the hart will enter debug mode if either is 1.

The configuration for sdedbgen is obtained from the manifest of the SD and is managed by the M-mode monitor in secure memory.

The external debug security extension will need to define the full rules around what is allowed in debug mode. When medbgen is 1, there are no restrictions. When medbgen is 0 but sdedbgen is 1, then the debug mode may be entered but has to have restrictions such as M privileged CSR accesses are prohibited and Memory accesses by instructions executed in debug mode cannot use M privilege. When medbgen is 0 and sdedbgen is also 0, then the rules around triggers configured with action=1 that may fire - such as always cause breakpoint exception.

[gokhankaplayan]

@ved-rivos's proposal is very similar to the secure debug proposal draft. I believe there are more details in this proposal about the debug behaviours: https://github.com/joxie/riscv-debug-security/blob/main/spec/Secure%20Debug%20Proposal.md

The difference is that medbgen is in Debug Module and managed by root of trust. Whereas M-mode external debug enabled is in a core CSR mdbgsec and managed by a M-mode secure monitor. I believe other differences are just about naming.

If we can align together in a meeting (Smmtt TG meeting or Secure Debug Proposal TG Meeting), we can merge the proposals.

[joxie]

Maybe I am wrong, but I think msdcfg is corresponding to mdbgsec in current external debug proposal.

medbgen looks more like system level debug enable/disable nob, maybe more accurate to say, it can be from authentication module or fuse block or even root of trust engien etc.

From very high level, I think the proposal makes sense, there're some differences need to be addressed.

1. It may be better to that debug control sits in a separate CSR because we want debug security to be able to function with and without Smmtt
2. The per-domain enable/disable nob as a whole makes perfect sense, now external debug security proposal has finer control granularity (V)U/(V)S/M, it may make sense to simplify the proposal to just M and sub-M. @gokhankaplayan what do you think

[gokhankaplayan]

@joxie, I agree with you about simplifying the proposal to M and sub-M. There is no use for more granular debug control.

[ved-rivos]

medbgen as shown is an external signal and can be driven by the authentication module or fuse block or RoT - thats why its shown as originating from the debug module. The msdcfg is not related to MTT - it holds configurations related to a supervisor domain. Whether the SD uses MTT or PMP for memory access control is orthogonal. The supervisor domain specific configurations held in msdcfg - including the external debug policy - are context switched per SD.

[gokhankaplayan]

In order to compare the proposals I drew the above diagram for External Debug Security TG proposal. I hope it reflects the latest consensus with @joxie. External debug enables of M-mode and Supervisor Domains are controlled by mdbgsec CSR. M-mode debug enable (mdbgen) has a lock bit for M-mode TCB. The default value of debug enable after reset is determined by SoC System, which is typically life-cycle fuse. The debug authentication, which interacts with DM registers (authenticated/authbusy/authdata) is considered orthogonal with the privilege based control. Debuggability in M-mode can be granted differently. E.g. ROM and Non-ROM code in M-mode can be isolated in terms of debuggability. I think the approaches to this use case are different in the two proposals.

[gokhankaplayan]

As a result of joint meeting of Smmtt TG and Debug Security TG-12/11/2023, the consensus is that there is machine mode debug enable should not be part Core CSR. Only supervisor domain debug enable will be part of a Core CSR.

[AoteJin]

As a result of joint meeting of Smmtt TG and Debug Security TG-12/11/2023, the consensus is that there is machine mode debug enable should not be part Core CSR. Only supervisor domain debug enable will be part of a Core CSR.

I think the concern is not M-mode debug enable being part of core CSR, but that the user have only supervisor mode debuggability cannot potential alter the debuggability of M-mode (e.g. by glitching or ROP etc.). The scheme posted by @gokhankaplayan looks promising. We could enforce different policy in lifecycle with the default value in mdbgsec (by fusing or authentication).

	mdbgen	mdbgen_lock	sdbgen
ROM debug phase	1	0	0
Secure monitor debug phase	0	0	0
Sub-M debug phase	0	1	0

In ROM debug phase, we could debug from the very beginning of ROM, because the chip is still in control of vendor. After this phase, the secure monitor could be debugged in a relatively trusted environment and the ROM could enable debug for secure monitor after it secure itself with PMP for example. Lastly, when the product is shipped, the M-mode debuggability is locked forever and secure monitor is responsible to manage sub-M mode debuggability.

[gokhankaplayan]

the ROM could enable debug for secure monitor after it secure itself with PMP for example

The issue is about the above statement. Instead of ROM itself, (HW or FW) RoT should enable debug for secure monitor. Therefore, mdgben should not be part of Core CSR.

As far as I understood It is potential security leak for privilege escalation attacks. The security experts in this group can clarify the security leak better than me.

[joxie]

the ROM could enable debug for secure monitor after it secure itself with PMP for example

The issue is about the above statement. Instead of ROM itself, HW RoT should enable debug for secure monitor. Therefore, mdgben should not be part of Core CSR.

As far as I understood It is potential security leak for privilege escalation attacks. The security experts in this group can clarify the security leak better than me.

That's correct. Basically we are saying M mode control should rely on a higher entity on CoT, either RoT or HW.

[ved-rivos]

Please also see the requirement SR_GEN_007 in the RISC-V security model

[AoteJin]

I am thinking if we move it out of CSR and keep only one signal mdbgen to control machine mode debuggability, we might lose the capability to manage life-cycle of machine mode code. What about we have HW CoT/RoT to determine the default value of mdbgen_lock and mdbgen? In this way, the M-mode debugablility is still in control of HW CoT/RoT, and there still the chance for different actors to manage lifecycle when HW RoT/CoT unlocks M-mode. BTW, CSR scales well if we have large amount of harts.

[AoteJin]

Revisited the idea of moving mdbgen out of CSR. Agree it will cover more larger range of use cases with RoT inside the hart or outside the hart. I think we could mandate a sideband signal in external debug spec coming from external to control machine mode debugability. Moreover, in order to meet SR_GEN_012 in RISC-V security model, the sideband signal should be clamped/locked until reset. Besides, since there is only one bit left in CSR per hart, it might be more economic to group it in mseccfg (0x747 on RV64).

[ved-rivos]

We should not allow M-mode to change its own debug ability. This exposes M-mode to issues where it may by error enable debug too early for example in its lifecycle. When a change in debug enable is required the M-mode should communicate with the RoT of M-mode to request a change in debug state. The RoT may then grant the request based on various considerations and policies - for example, the RoT may check that suitable SoC wide configurations have been locked down prior to allowing debug at M-mode, there may be a need to check that all harts in the SoC have reached identical life cycle state before allowing any hart to be debugged in M-mode, etc. The SR_GEN_012 mandates that the debug enable for M-mode must not be controlled by M-mode but must be only controlled by the RoT of M-mode.

[rsahita]

Please see PR 20 @joxie @gokhankaplayan @ved-rivos

[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

[rsahita]

merged #20 (i think the above comment from Jin is a separate issue - if required please open it separately Jin)