Re: [RISC-V] [tech-tee] TEE proposal for M-mode SMEP/SMAP via PMP
Στις 2019-12-22 03:12, Greg Favor έγραψε:
I notice another seeming issue, in the "rationale" for item 3a, whereIn 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 beThe 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.