Conversation
|
|
||
|
|
||
| * When the Smsdid extension is also implemented: | ||
| ** The current supervisor domain identifier (SDID). |
There was a problem hiding this comment.
I think it's a good idea to make SDID apply to M-mode, and would consider expanding the concept beyond SDID:
U-mode code might be able to trigger M-mode execution (say though instruction emulation traps).
If different ASIDs share the same M-mode predictors, a cross-domain attack through M-mode software is theoretically possible.
Without hardware domains based on ASID/VMID in M-mode, secure M-mode software should issue fence.hpd for exceptions that come from outside of M or HS-mode, since M-mode might be using predictors trained by a different domain.
The domain could be decided by mstatus.MPP and mstatus.MPV:
MPP=M -> M (dropping SDID since mmpt is not affecting M mode in any way)
MPP=[SU] MPV=0 -> M + SDID + satp.ASID
MPP=[SU] MPV=1 -> M + SDID + VMID + vsatp.ASID
(Similar for HS and hstatus.SPVP.)
|
|
||
| Executing `fence.hpd` may incur substantial overhead. Execution of `fence.hpd` | ||
| is required only when an identifier is reused. If an implementation provides a | ||
| sufficiently large identifier space, reuse is infrequent, which mitigates the |
There was a problem hiding this comment.
SPMP has identifier space of 1, requiring a fence.hpd on each context switch.
Since the IDs are not limited to TLB state anymore, do we want to allow SDID/VMID/ASID with Bare modes?
2 participants
No description provided.