Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements
Yes, the reason I labelled it separate M&L was because the existing "legacy" proposal essentially combines the functionality into a single "L" bit.
> 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 v either intentional or that M-mode code is buggy, in my opinion.
Such an entry is impossible under the existing standard. There's no way to encode it.
Of course - I was referring to sep_M&L proposals, (e.g. with MML=1, L=1, M-0). Sorry for the confusion - too many proposals floating around.
The enhanced proposal can make a region inaccessible to M, accessible to S/U - but doesn't allow it to be locked.
I do understand that if you want to ensure that a locked rule can't be undone, you need ensure that all entries with lower entry numbers than it are also locked.
That's another way of saying that we shouldn't be inventing new modes to prevent this, we just need to do avoid obvious buggy code (I don't know if any of the proposals actually do something like that, so don't take that as criticism).
Mr. Kurd's proposal does not similarly lock down all of M mode's executable regions against modification nor prevent the creation of new PMP entries for executable regions.
Well, that would be a pretty simple modification of his proposal, then: disallow creation of new Mode X regions when MML=1.
If that modification was made, what drawbacks remain?
I do understand that this might require a particular BootRom coding sequence; I'd like to explore that to see if it would be unreasonable or not.
I don't see an equivalent of the shared data regions that the sepM&L and enhanced proposals have.
There is something similar that allows S/U to have execution privileges in a shared access region and only if it is unlocked, and I don't know if that should be a concern or not.
I'd still like to simplify either proposal by removing DMC and replacing it with "any entry locked".
Once you've locked a region, there is no need to access unmapped regions, since you can do that from the locked region