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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

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

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

It seems like the current trade-off in supported use cases is due to the combination of two constraints: backward compatibility and avoiding use of a Reserved PMP bit. A year ago the exact degree of

As promised, here is my suggestion for modifying the TEE Task Group's "PMP Enhancements" proposal to have four security levels, to support a larger set of use cases. Instead of the two bits MML and

I wrote: "I assume there is also an independent DMC bit (Default Memory Closed)." - John Hauser