Reformulation for "fencing when changing SDID"

[ronan-lashermes]

I believe this phrase could be clarified:

riscv-smmtt/chapter3.adoc

Line 11 in 8879b1a

changed at the cost of fencing to flush any prior cached state. The SDID is

To me, "cached state" suggests only the need to flush specific microarchitectural caching structures (such as TLB, L1D, L1I). However, from a security standpoint, the correct action involves flushing all microarchitectural state, including components like branch prediction (BTB, RSB, TAGE) and cache controller states.

Suggested revision:

"However, the SDID can be changed at the cost of fencing to flush any prior microarchitectural state"

Still, I am unsure if this phrasing would be sufficiently clear for readers unfamiliar with the risks associated with covert channels.

[rsahita]

Hi Ronan - this specification does not delve into any treatment of flushing any micro-arch state when supervisor domains are in use. The security model and the uarch side-channel specs are the right place for that treatment. The goal of this sentence was to note that the SDID is a hart-local identifier and may be reused as long as the state tagged by the re-used SDID is appropriately flushed.

per your comment - i think these two lines should be moved to an "implementation note" - I plan to change it as follows - PTAL:

For most typical usages, the SDID will remain stable over the life
of the supervisor domain. However, the SDID can be changed
at the cost of fencing to flush any prior cached state that was
associated with the SDID.

[ronan-lashermes]

Ok, as I understand it, the SDID is a security domain identifier and therefore, upon changing it, should quite naturally trigger a fence.time kind of flushing/partitioning. As you say, the details should be left to the fence.time spec.

What I wanted to say is that flushing cached state is required for proper functionality, flushing all state (with fence.time for example) is required for security. In a hypothetical future with fence.time, fence.time is the instruction that should trigger the flushing, including the cached state.

Moving this sentence to an implementation note is a great solution, but I think you can remove the "fencing to" for clarity.

For most typical usages, the SDID will remain stable over the life
of the supervisor domain. However, the SDID can be changed
at the cost of flushing any prior cached state that was
associated with the SDID

[rsahita]

sounds good PTAL PR #109