search

riscv-non-isa / riscv-external-debug-security

The RISC-V External Debug Security Specification
https://jira.riscv.org/browse/RVG-136
Creative Commons Attribution 4.0 International
18 stars 2 forks source link

Per priviledge-mode debug control #12

Closed joxie closed 3 months ago

joxie commented 7 months ago

Open this ticket to track potential need for per privilege control for external debug / trace

joxie commented 7 months ago

@AoteJin can you update your discussion with Penglai guys

AoteJin commented 7 months ago

Penglai team claim that their architecture does not requirement per privilege-mode debug control. They could accommodate current proposal by:

gagachang commented 7 months ago
  • Add supervisor RT layer for debug of u-mode only partition

Hi, What if CPU only implements M+U without S-mode?

gagachang commented 7 months ago

Hello @AoteJin Would you like to explain what per privilege-mode debug control means ? I might miss the discussion in previous TG meeting.

AoteJin commented 7 months ago

Hello @AoteJin Would you like to explain what per privilege-mode debug control means ? I might miss the discussion in previous TG meeting.

I would love to. The external debug security proposal has two level control: machine (from RoT) and submachine (by M-mode CSR).

What if CPU only implements M+U without S-mode?

In an implementation without S-mode, these two controls are enough to separately manage debuggability of M and U.

This issue is to discuss the case that an implementation has privilege levels more than M/U (e.g. M/S/U) and machine mode launches directly to U-mode. This might be a problem because submachine mode control does not differentiate S/U and results in privilege escalation in terms external debug.

gagachang commented 7 months ago

What if CPU only implements M+U without S-mode?

In an implementation without S-mode, these two controls are enough to separately manage debuggability of M and U.

Yes, U-mode external debug can be managed by sdbgen, in M+U system. Thanks!

This issue is to discuss the case that an implementation has privilege levels more than M/U (e.g. M/S/U) and machine mode launches directly to U-mode. This might be a problem because submachine mode control does not differentiate S/U and results in privilege escalation in terms external debug.

What the privilege escalation is here? Do you mean debugger could read S-mode CSR or memory (e.g., satp, stvec) ? Because maximum debug privilege is S-mode when mdbgen=0 and sdbgen=1

AoteJin commented 7 months ago

What the privilege escalation is here? Do you mean debugger could read S-mode CSR or memory (e.g., satp, stvec) ? Because maximum debug privilege is S-mode when mdbgen=0 and sdbgen=1

Yes, this is exactly the concern.

gagachang commented 7 months ago

Another problem is dcsr.PRV ? U-mode debugger can write dcsr.PRV as S-mode (Because maximum debug privilege is S-mode) and dret to S-mode, am I correct?

AoteJin commented 7 months ago

Technically, there are only M-mode debugger and subM-mode debugger defined in proposal. And the subM-mode debugger can write dcsr.PRV as S-mode then dret.

I agree it is another attack vector for privilege escalation.

gagachang commented 7 months ago

Hmm.. The hart knows the previous privilege mode (i.e., U-mode) when the hart enters Debug Mode.

In external debug security spec section 3.4.1 says:

It will generate a security fault error (cmderr 6) if the external debugger attempts to configure prv and v with a privilege higher than the maximum debug privilege level.

Maybe it can changed to: It will generate a security fault error (cmderr 6) if the external debugger attempts to configure prv and v with a privilege higher than the "previous" privilege level.

I mean, when external debugger executing abstract commands to read/write CSR, memory, hart can check both maximum debug access privilege and "previous" privilege level. For example, dcsr.PRV can not be configured to S-mode if previous privilege level is U-mode.

AoteJin commented 7 months ago

I mean, when external debugger executing abstract commands to read/write CSR, memory, hart can check both maximum debug access privilege and "previous" privilege level. For example, dcsr.PRV can not be configured to S-mode if previous privilege level is U-mode.

This is not directly related to this ticket. If you have concern on it, would better to discuss it on a separate issue. The reason not checking against previous privilege is that the subM debugger might stop on U-mode and it will need higher privilege "view" to debug the U-mode, e.g. VA->PA mapping etc. We do not want to break this use case.

gagachang commented 7 months ago

subM debugger might stop on U-mode and it will need higher privilege "view" to debug the U-mode, e.g. VA->PA mapping etc. We do not want to break this use case.

@AoteJin Thank you ! Now I understand why the spec specifies maximum debug access privilege rather than previous privilege level.

joxie commented 6 months ago

Closing. Based on the information TG has as of today, we do not see a need to have fine grain control.