Advice about enabling all state is potentially harmful

[jrtc27]

Currently the spec has the following:

If software at any privilege level does not support multiple contexts for less-privilege levels, then it may choose to maximize less-privileged access to all state by writing a value of all ones to the stateen CSRs at its level (the mstateen CSRs for machine level, the sstateen CSRs for an OS, and the hstateen CSRs for a hypervisor), without knowing all the state to which it is granting access. This is justified because there is no risk of a covert channel between execution contexts at the less-privileged level when only one context exists at that level. This situation is expected to be common for machine level, and it might also arise, for example, for a type-1 hypervisor that hosts only a single guest virtual machine.

This is only safe if that state does not affect the current privilege level. However, extensions could introduce state that affects the current privilege level but is shared between multiple levels and so should not be writable by lesser privileged levels unless the current privilege level knows to restore it in its entry point. This would be totally safe without this recommendation, but this recommendation means that such cases are very unsafe.

Note that our current design of CHERI-RISC-V hits this exact case with our default data capability, though our design predates Smstateen by multiple years and so does not currently use it (but presumably should, were it not for this issue; currently to work around it we'd likely have to have the stateen bit just enable access to a separate CSR that then allows for the extension to actually be properly enabled).

There's also the related case where the shared state doesn't affect the current privilege level but is implicitly mutated by operations performed by the current privilege level, and so entering and exiting the current privilege level will clobber it for the less privileged level.

This case is also hit by CHERI-RISC-V, since our capabilities extend the integer register file, but any normal RISC-V instruction that just writes to the integer part of the register will clear the capability metadata, much like how setting UXLEN=32 writes zero-extended values on an RV64 system.