Description
Open an issue to track 0.6.0 feedback and 0.7.0 dev
Below are a list of feedbacks we collected from v0.6
https://lists.riscv.org/g/tech-external-debug-security/message/255
https://lists.riscv.org/g/tech-external-debug-security/message/264
https://lists.riscv.org/g/tech-external-debug-security/message/268
Wording & non-normative notes
Section 3.1 - "Quick Access" Abstract Commands, which do not require the hart to be in the halted state, will be
dropped and set
- Add a non-normative note to clarify the purpose (safeguard)
Section 3.1 For example, once the software completes executing confidential code, it can grant debuggability for an external debugger. Afterwards, the software can enter a while(1) loop, waiting for the debugger to take control and break out of the loop.
- Re-write this note / or consider remove
- Clarify how halt-after-reset works with Sdsec in a separate note/section, currently it is not specified
Section 3.1.6
The use case is just for real-time but (more importantly) for security
- Fix/enhance wording for note
Section 3.3.2
- Fix/enhance wording
Appendix A.1
- Fix/enhance wording
Section 4.5.1 (hardwire vs read-only)
Probably no action here, debug spec uses many hardwired (is there any document on terms)
Section 3.1:
- Formatting issue for bullets after " Debug operations affected by Sdsec:"
- Best to indicate what "action=1" means. Could say "action=1 (Enter Debug Mode)".
- Fix wording
Section 3.1.1:
- "When mdbgen is set to 0, the debug operations are disallowed and the behaviors applies when the hart runs in M-mode." > This is not very clear. Suggest: "When mdbgen is set to 0, external debug is disallowed in M-mode. See Section 3.1 for how
this impacts hart behavior."
- Fix wording
Section 3.3.1:
- Probably best to mention that dmode is a field in tdata1
- Fix wording
Section 3.4.1:
- Either include all the dcsr fields in the diagram, or don't have a diagram. Same for later DM registers.
- Fix wording
Section 3.4.3:
- "The CSR holding the debug and trace control knobs for supervisor domain" I assume "knobs" is referring to the sdedbgalw and sdetrcalw bits? Better to refer to them explicitly, and the CSR name.
- Fix wording
Chapter 2: How does the spec address the boot ROM scenario security issue ?
- Add non-normative note to clarify how to allow M-mode FW debug and disallow BR debug
Section 3.2:
- "The availability of trace output is indicated through the interface defined in RISC-V Efficient Trace for RISC-V [2] to trace module.". N-trace is now ratified as well.
Discussed in riscv-non-isa/riscv-trace-spec#98 and decided to document the change in Sdsec to avoid additional ratification work
- Document e-trace change in Sdsec spec
Arch opens
Section 3.4.1, what's the rationale for not authorizing external debuggers in S-mode to use the dscratch* registers?
- [ ]
Activity