Charter update (#7)

* Update

* update

* Update

* Update CHARTER.md according to review feedback

Signed-off-by: Joe Xie <joxie@users.noreply.github.com>

* Update CHARTER.md

Signed-off-by: Joe Xie <joxie@users.noreply.github.com>

* Update CHARTER.md

Signed-off-by: Joe Xie <joxie@users.noreply.github.com>

---------

Signed-off-by: Joe Xie <joxie@users.noreply.github.com>

CHARTER.md

@@ -1,12 +1,11 @@
 # External Debug Security Task Group Charter
 
-The growing complexity of modern System-on-Chip (SoC) designs has led to a corresponding increase in the need for effective debugging capabilities. However, the use of debugging functions also introduces potential security vulnerabilities that can be exploited by attackers to gain unauthorized access to sensitive information or perform malicious actions on the system. Modern SoC development consists of several different actors who may not trust each other, resulting in the need to isolate actors’ assets during development and debugging phases. The current RISC-V Debug Support specification grants the external debugger highest privilege in the system, regardless of the privilege level at which the target system is running. It leads to privilege escalation issues when multiple actors are present. For example, the owner of a SoC, who needs to debug their M-mode firmware, may be able to use the external debugger to bypass PMP.L and attack Boot ROM (the SoC creator’s asset).
+The growing complexity of modern System-on-Chip (SoC) designs has led to a corresponding increase in the need for effective debugging capabilities. However, the use of debugging functions also introduces potential security vulnerabilities that can be exploited by attackers to gain unauthorized access to sensitive information or perform malicious actions on the system. Modern SoC development consists of several different actors who may not trust each other, resulting in the need to isolate actors’ assets during development and debugging phases. The current RISC-V Debug specification grants the external debugger highest privilege in the system, regardless of the privilege level at which the target system is running. It leads to privilege escalation issues when multiple actors are present. For example, the owner of a SoC, who needs to debug their M-mode firmware, may be able to use the external debugger to bypass PMP.L and attack Boot ROM (the SoC creator’s asset).
 
-The mission of the RISC-V External Debug Security Task Group is to define ISA and non ISA extensions to address the above security issues in the current RISC-V Debug Support specification. More specifically, the TG aims to define a mechanism to control (enable/disable) external debug of M-mode and to control external
-debug of supervisor domains according to their debug policy. The mechanism shall be generic enough to be applicable to RISC-V isolation models, for example, WorldGuard and [Smmtt](https://github.com/riscv/riscv-smmtt). It will also consider some temporal isolation boundaries, for example protection of immutable boot code. Additionally, the isolation mechanism will be extended for RISC-V Trace Control Interface Specification, which already defines the mechanism to filter trace per privilege level without providing protection for vicious configuration. The TG will also address this gap to provide required isolation for trace.
+The mission of the RISC-V External Debug Security Task Group is to define non-ISA extensions and ISA extensions, such as ISA extension to restrict debug mode behavior in Sdext, to address the above security issues in the current RISC-V Debug specification. More specifically, the TG aims to define a mechanism to control (enable/disable) external debug of M-mode and to control external debug of supervisor domains according to their debug policy. The mechanism shall be generic enough to be applicable to RISC-V isolation models, for example, WorldGuard and [Smmtt](https://github.com/riscv/riscv-smmtt). Additionally, the isolation mechanism will be extended for RISC-V Trace Control Interface Specification, which already defines the mechanism to filter trace per privilege level without providing protection for vicious configuration. The TG will also address this gap to provide required isolation for trace.
 
 The TG will assume that a system provides a debug authentication module at system level, for example as part of a HW RoT. The authentication mechanism or protocol is currently out of TG’s scope, it may be considered in future iterations. 
 
 The TG will develop the written specification, simulator (Spike and/or QEMU), compliance (ACT test) and Sail (model) specification for the RISC-V external debug security extension(s). 
 
-The TG will interface with Runtime Integrity (RTI) SIG, Smmtt TG under RTI SIG and DTPM SIG.
+The TG will interface with Runtime Integrity (RTI) SIG, Smmtt TG under RTI SIG and DTPM SIG.