Nick Kossifidis wrote:
> Finally
> when MSL=3 and PL=3 we get removable M-mode-only, non-executable
> regions, at the highest security level. In terms of security it's a
> regression over revision 0.2, not an improvement.
That detail could easily be changed, if that's the only remaining
complaint about the security.
I don't understand how having extra bit patterns for the PMP config registers compromise security. Isn't it pretty much a given that the values loaded into the PMP address registers and PMP config registers (and all other security relevant CSRs: mtvec, satp, mideleg, etc.) must be correct? If having a "M-mode-only, non-executable region" doesn't match your security goals, then don't program one?
Nick Kossifidis wrote:
As shown above, restricting M-mode from executing memory regions without
a matching rule, only makes sense if it's not possible to add such a
rule (that allows execution). If it's possible to add a rule that
applies to M-mode then any restrictions regarding regions without a
matching rule, are a few instructions away from being bypassed.
The restriction still makes sense as a form of defense in depth. Plus, "a few instructions" at elevated privilege is a rather high bar. That is all it takes to escape from a Javascript sandbox, to escalate from user mode to kernel mode, or to break out of a VM. Yet, in all of those isolation mechanisms provide a very real security because even the bugs they do have still leave it rather hard to execute specific desired instructions.
