Trace Enable as part of mdbgsec CSR

[gokhankaplayan]

RISC-V Trace Control Interface Specification defines the mechanism to filter trace per privilege level (trTeFilterMatchChoicePrivilege) without providing protection for vicious configuration: https://github.com/riscv-non-isa/tg-nexus-trace/blob/master/docs/RISC-V-Trace-Control-Interface.adoc#63-trace-encoder-filter-registers

There are two alternatives to protect privilege level configuration:

• Machine Debug Security Control Register (mdbgsec) includes trace control (trcen,trcv,trcprv) and this information should be reflected on Trace Ingress interface between trace encoder and Core (See E-Trace specification for Ingress Interface). Trace encoder shall compare mdbgsec.(trcen, trcv,trcv) with trTeFilterMatchChoicePrivilege to determine legal configuraitons.
• Trace Security Control Register is added as part of RISC-V Trace Control Interface Specification. Since it is a memory mapped register, only M-mode programming feature should be provided with implementation specific ways.

[AoteJin]

The option 1 seems more promising. Since the mdbgsec is a mchine mode CSR, it is naturally protected by CSR access rule and general for all RISC-V platform. In controry, the option 2 has deviation in protection mechanism of MMIO.

[AoteJin]

add mdbgsec info in trace ingress port and tracer to enforce privilege control on it

[AoteJin]

Rethinking of the trace control. I think the privilege control could still happen inside hart boundary and the hart could clamp the ingress port if the privilege does not suffice. The hart could use halt sideband signal (defined in E-trace spec) to tell encoder to stop generating trace packets and resync all trace module internal state. The upside is that this solution will leave the trace module in a clean state if the higher privilege mode conducts the context switch. We should enforce that when there is a privilege switch, all trace of previous privilege should be yielded to trace module, while the trace of next privilege should not be escaped in advance

[gokhankaplayan]

Instead of halt sideband signal, trigger sideband signal (trace-on and trace-off) might be more appropriate to use it. I think the both have the same functionality, but halt sideband signal explicitly means it is halted in debug mode.

[AoteJin]

I agree they are to certain extend similar. But the trigger signals are controlled by trigger as well, which means there will be potential two drivers of the signal pair, one is trigger module and the other is mdbgsec privilege control. The adversary might exploit the trace condition to cancel privilege control. E.g. the debugger is allowed in S-mode and set a trace-on breakpoint at the pc of ecall with timing is after execution. There will be race of trace-on and trace-off signal and potentially cancel the privilege control. Same applies to other exceptional cases.

[gokhankaplayan]

I understand the race condition. I think it can be solved with careful implementation, but it will bring more design complexity. So, I am fine with your proposal of using halt sideband signal. As an additional concern, some trace encoders might have configuration to trace debug mode. I think this feature is redundant and not defined in the standard (https://github.com/riscv-non-isa/tg-nexus-trace/blob/master/docs/RISC-V-Trace-Control-Interface.adoc). So, halt sideband signal is fine to use it.

[AoteJin]

Close. The issue is discussed now in smmtt TG