"The problem occurs when an extension adds processor state---usually explicit registers, but possibly other forms of state---that the main OS or hypervisor is unaware of (and hence won’t context-switch) but that can be modified/written by one user thread or guest OS and perceived/examined/read by another" and so forth.
Also: "Obviously, one way to prevent the use of new user-level CSRs as covert channels would be to add to mstatus or sstatus an "XS" field for each relevant extension, paralleling the V extension’s VS field. However, this is not considered a general solution to the problem due to the number of potential future extensions that may add small amounts of state."
CX addresses this covert channel problem, in three ways:
1) a CX-agnostic CX-aware OS controls access to all CX state contexts of a user thread;
2) the OS can save/restore any CX state context, now or to come;
3) every CX state context has a CX state context word with a scxs_status.CS (maybe rename to .XS).
Presently CX is 100% orthogonal to Smstateen. Is there a need to bend one to the other?
Also CX still needs work to enable hypervisor systems (requires another Issue to elaborate).
Like Smcsrind, Smstateen should be listed as an overlap/interaction in the CX TG Charter, and explicitly addressed in the spec.
Smstateen overlaps the problem space and solution of composable extensions' state contexts. Arguably less well. (See also Ssstaten.)
See https://github.com/riscv/riscv-state-enable/releases/download/v1.0.0/Smstateen.pdf which although ratified is not yet integrated into: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-af07c84-2024-03-26/priv-isa-asciidoc.pdf
"The problem occurs when an extension adds processor state---usually explicit registers, but possibly other forms of state---that the main OS or hypervisor is unaware of (and hence won’t context-switch) but that can be modified/written by one user thread or guest OS and perceived/examined/read by another" and so forth.
Also: "Obviously, one way to prevent the use of new user-level CSRs as covert channels would be to add to mstatus or sstatus an "XS" field for each relevant extension, paralleling the V extension’s VS field. However, this is not considered a general solution to the problem due to the number of potential future extensions that may add small amounts of state."
CX addresses this covert channel problem, in three ways: 1) a CX-agnostic CX-aware OS controls access to all CX state contexts of a user thread; 2) the OS can save/restore any CX state context, now or to come; 3) every CX state context has a CX state context word with a scxs_status.CS (maybe rename to .XS).
Presently CX is 100% orthogonal to Smstateen. Is there a need to bend one to the other? Also CX still needs work to enable hypervisor systems (requires another Issue to elaborate).
Like Smcsrind, Smstateen should be listed as an overlap/interaction in the CX TG Charter, and explicitly addressed in the spec.