For 4.. As we discussed in the meeting we agree with the use case, lock is existing in current PMP. The current PMP enhancement proposal tries to be back compatible and thus does not try to address

I wrote: Correction: I believe that should say "... implicitly grants read permission to S/U modes when in M mode and MXR = 1". This is relevant only when MPRV = 1 and MPP = 0 or 1, so it's a rather

Hello all, I've been studying the TEE Task Group's "PMP Enhancements" proposal with great interest off-and-on for several weeks. I definitely agree with the intention of the proposal, but I see

ACK, I'll update the doc accordingly. Regards, Nick

Good point, Allen. I think it would make good sense to begin assigning mCause values >= 64 where there's no likelihood of wanting a rapid delegation to a privilege below M. The Security Exception is

I have just noticed a minor spec hole here: the new security exception has mCause=16. The question is, whether xEDELEG[16] is RW or must be fixed as WARL 0? I am assuming it must be fixed to 0, but

A while back, it was proposed that the Ztso extension (which strengthens the memory model to RVTSO instead of RVWMO) be discoverable via the misa.T bit. The T bit had been tentatively reserved for a

Hello Greg, Στις 2019-12-22 03:12, Greg Favor έγραψε: 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.

Hello Greg and thanks for your feedback ! Στις 2019-12-21 05:04, Greg Favor έγραψε: Good point, I've updated the document so that writing pmpcfg.L and pmpcfg.X while MML is set is ignored.

I notice another seeming issue, in the "rationale" for item 3a, where it says: First, it would be good for this rule locking behavior to be explicitly included in item 3's description of the

The other possibility is to simply write it, but any access that is matched by it (and not overridden by another with a lower index?) causes a security exception. That is actually how I thought it did

Is it worth adding a generic rationale comment, for example around the definition of WARL? Paolo

Although I still haven’t grokked the proposal, I can say I agree with your line of reasoning. This use case doesn’t justify crossing the Rubicon of data-dependent traps. Your proposed solution

I’ve been keeping track of it, and I’m pretty happy with it. -Allen

This all looks very good, except for one issue with item 3b: "Adding a new PMP rule with pmpcfg.L and pmpcfg.X bits set fails with Security exception." RISC-V architecture - rather nicely - currently

Excellent point, Greg. I think either nop or setting a security error bit (which would cause an error the next time the entry or the PMP was used) would be better than making the exception depend on

PrivArch folks, The TEE TG has proposed additional PMP functionality to mitigate some forms of security attack against M-mode. A description of the threat model and the proposed augmentation is at