Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP
|
Greg Favor
I notice another seeming issue, in the "rationale" for item 3a, where it says:
First, it would be good for this rule locking behavior to be explicitly included in item 3's description of the behavioral changes when mseccfg.MML is set. Second, is the intent of MML=1 that no more M-mode-only rules can be added, or that only the existing M-mode-only rules can't be modified? The latter more corresponds to the current Lock behavior, but this opens the door to being able to add a higher priority (lower numbered) M-mode-only rule that overrides an existing locked rule (or an existing non-locked S/U-mode-only rule). Similarly the door is open to changing an S/U-mode-only rule into an M-mode-only rule and giving M-mode access to what used to be an S/U-mode-only area or memory. In essence all these "doors" enable the intent of this PMP enhancement proposal to be circumvented. If the answer is that no more M-mode-only rules can be added when MML=1, then this is still worrisome or at least uncomfortable. Attacked M-mode software could still change S/U-mode-only rules in some way that enables some sort of subtle security attack. Or the attacked M-mode software modifies M-mode-only memory, then writes a new overriding rule that makes that memory now accessible to S/U-modes. The nature of an actual attack is not clear, but it is concerning that someone with enough ingenuity could maybe mount a security attack through playing games with the PMP rules that are not currently locked. But then again, I guess this risk (arguably low or minimal)
is necessary
to allow the flexibility for M-mode to dynamically manage and change the non-M-mode-only rules during system operation. So I can't really argue against "the answer is that no more M-mode-only rules can be added when MML=1". And whatever risk there is could be mitigated a bit by maybe (?) explicitly recommending that locked rules should all occupy the lowest numbered PMP entries, ahead of any and all non-locked rules. Greg On Fri, Dec 20, 2019 at 3:23 PM Andrew Waterman <andrew@...> wrote:
|
|
|