timedelta for supervisor domains

[gagachang]

Priv. spec. defines htimedelta to have a delta between the value of the time CSR and the value returned in VS-mode or VU-mode. IIUC, this mechanism can only work in single supervisor domain which has HS-mode hypervisor.

However, now we have multiple supervisor domains which have there own OS or hypervisor, respectively. Does it make sense to add new similar CSR (e.g., sdtimedelta) for active supervisor domain ? Thus, some supervisor domains can not see real time value.

[rsahita]

Hi @gagachang - Can you please elaborate on your use case on why would we want to prevent supervisor domain from seeing real time value? Supervisor domains do not try to virtualize/hide HW resources such as a hypervisor tries to do - it is enforcing isolation. The RDSM in M-mode can context switch the CSR fields (including htimedelta if a supervisor domain is using HS-mode) so that supervisor domain can retain control for its workloads - But even so, time gaps will be visible to a supervisor domain - the RDSM will take some execution time, for example, and it is known to the supervisor domain.

[gagachang]

Hmm, actually I am not sure, so I raise this question. The competitive architecture has dedicated timers for each security world. Several papers also showed the timing side channel attacks due to the precise timers.

But even so, time gaps will be visible to a supervisor domain - the RDSM will take some execution time, for example, and it is known to the supervisor domain.

Maybe it is a kind of timedelta, I agree.

[ved-rivos]

The competitive architecture has dedicated timers for each security world.

Dedicated timer makes sense and the Supervisor Domains provides it through the Sstc extension. The SD can program stimecmp and vstimecmp. The RDSM would context switch these and as part of context switch also add the deadlines to its list of timers - so it can schedule the SD when the deadline approaches.

[gagachang]

Dedicated timer makes sense and the Supervisor Domains provides it through the Sstc extension. The SD can program stimecmp and vstimecmp. The RDSM would context switch these and as part of context switch also add the deadlines to its list of timers - so it can schedule the SD when the deadline approaches.

The point here is not stimecmp and vstimecmp. The point here is the value of time read by supervisor domains. By adding sdtimedelta CSR, reading the time CSR in "HS", "S" or "U" mode could return (time + sdtimedelta). Which prevents supervisor domain from seeing real time value.

Supervisor domains do not try to virtualize/hide HW resources such as a hypervisor tries to do - it is enforcing isolation.

Now I agree to what @rsahita said. I just tried to consider any potential attacks. Maybe timing side channels can be overcome in uSC SIG ?

[rsahita]

@gagachang right - side-channels are an issue for any privilege separation model and the uSC TG proposals on fence.t and other micro-architectural mechanisms used by implementations should be used to prevent those. These mitigations are highly implementation specific though. Context switches go through the RDSM so that allows implementations to introduce use of those micro-architectural mechanisms via the RDSM.

Are you ok to close this issue?

[gagachang]

@gagachang right - side-channels are an issue for any privilege separation model and the uSC TG proposals on fence.t and other micro-architectural mechanisms used by implementations should be used to prevent those. These mitigations are highly implementation specific though. Context switches go through the RDSM so that allows implementations to introduce use of those micro-architectural mechanisms via the RDSM.

It makes sense, thanks!