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:
The rule locking becomes part of the definition of an M-mode-only rule, since when a rule is added on M mode, if not locked, can be modified or removed. On the other hand, S/U modes can’t modify PMP rules anyway so locking them doesn’t make sense.  

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.


On Fri, Dec 20, 2019 at 3:23 PM Andrew Waterman <andrew@...> wrote:
PrivArch folks,

The TEE TG has proposed additional PMP functionality to mitigate some forms of security attack against M-mode.  A description of the threat model and the proposed augmentation is at the link below.  Please review and provide feedback on this thread; I'll do the same shortly.


Join { to automatically receive all group messages.