Hello Greg,

Στις 2019-12-22 03:12, 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.

In the current PMP spec, the only way for a rule to be enforced on M-mode is for that rule to have the L bit set, hence being locked. This behavior doesn't change, what does change is that such rules are now enforced _only_ on M-mode and not also on S/U-modes. We do mention this on 3a:

"An M-mode-only rule is enforced on Machine mode and denied on Supervisor or User modes. It also remains locked so that any further modifications to the configuration or address registers are ignored until system reset."

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.

The idea as mentioned on 3b is to prevent new executable M-Mode-only rules to be added. We can't do much about M-mode accessing S/U mode's memory, it can either add a higher priority M-Mode-only rule (however this will prevent S/U-mode from accessing that region and the software there will probably crash), use MPRV, or temporarily remove the S/U-mode-only rule that corresponds to that region and access it (M-mode can still access regions without a corresponding PMP rule). Trying to further restrict this will make things much more complicated on the software side, increasing the probability of security bugs, and will greatly reduce flexibility.

The goal of this proposal is to limit the attack surface in the same way SMEP/SMAP limit the attack surface on Supervisor mode. On S-mode one can still create new virtual memory mappings or remove the U bit from the PTE and circumvent SMAP/SMEP, but it's still a useful feature to have and relatively cheap. In our case execution prevention is much more strict since M-mode can't add any more executable regions for itself (3b), and can only execute code from marked regions (3c) so memory access prevention may be circumvented but memory execution prevention can't be circumvented and MEP is the real deal here, especially on M/U systems where the whole OS will be running on M-mode.

Also note that the attack vector we are after, as mentioned on Introduction/Threat model, includes an attacker that can leverage a bug on M-mode to trick it and make it execute code from an attacker-controlled S/U memory region. We can't do much if an attacker has fully compromised M-mode in a way that he/she can tweak with PMP rules or set CSRs in general, in the same way we can't do much if an attacker has such control on S-mode where he/she can tweak with the page table. In such a scenario it's game over.

Regards,
Nick