[RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements
toggle quoted messageShow quoted text
You need to be careful with terminology. I am assuming that
"denying access to Mmode" means
"denying the ability of M-mode to change an entry" , and not
"denying access to the region defined by an entry".
But: if an entry is created (necessarily by M-mode) that is locked and such that M-mode can no longer touch that region but S/U mode can - that is either intentional or that M-mode code is buggy, in my opinion. And, even if that happens, M-mode code code always define an unlocked region of higher priority (unless it has allocated all the higher priority regions). Again, intentional or buggy M-mode code. We can't defend against stupid buggy code.
I also don't see why M&L (I assume you mean the current enhanced proposal) can't lock down a region which is executable, but I'm unclear what exactly you mean by this.
A region which is intended to be executable (by Mmode only) can be made as L-RX, so that code can no longer be altered, and when MM is set to 1 only Mmode code can execute it.
That's not much different than the separate M+L. I thought the reason for separate M+L was to give the ability to have unlocked unwritable regions that were inaccessible to S/U mode (so the M-mode region could be expanded without requiring using new entries).
IF you didn't care about the unwritability, you can do this with the current enhanced proposal.
There are a lot of hidden assumptions about the use model here, e.g. is it permitted to leave M-mode before the final (locked) M-mode configuration has been set up?
If not (and I'd like to know why that isn't a reasonable assumption) then separate M+L seems a bit less important.
Could you give me a more complete example where the current enhanced proposal doesn't do what you want?
On Wed, Feb 19, 2020 at 1:15 PM Jonathan Behrens <behrensj@...> wrote: