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 the

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 t

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 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 behaviora

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 th

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 t

>A while ago, I expressed opposition to consuming one of the remaining pmpcfg bits because it seemed, >at the time, that the goals of this proposal could be accomplished without doing so. If that is n

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 severa

It's not just for glitch protection, but also for security to control access permissions. The software is loaded from the boot ROM and the boot ROM does not contain software to unlock the PMP entries

Hi Nick, Thanks for the feedback, and I understand your arguments. When you say "It" above are you talking about: 1. my original proposal (DMC and DPL) 2. my updated proposal (M-bit in each PMP entry)

Nick Kossifidis wrote: I'd like to point out that my own proposal does always allow for the locking of regions for the next boot stages, when that's appropriate. If unlocked M-mode PMP entries can't b

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 MM

Thanks Allen and John, I found John's version easier to read and I have added an extra sheet "permissions" to it showing the effect of the 4 different schemes. I give an idea of how to program the dif

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 ent

Hello all, Concerning the proposal from Tariq Kurd (Huawei) with separate M and L bits in PMP configuration bytes, in my view there are two details that should disqualify it from consideration, at lea

I wrote: Allen Baum: Sorry, I meant that, under the existing standard, locked PMP entries are intended to deny some or all accesses from M mode to a memory region. The RISC-V standard says, "In additi

I wrote: Allen Baum: By the "M & L proposal" I meant Tariq Kurd's proposal, the one I was speaking of. (On your own cheat sheet from yesterday, the tab for this proposal is labeled "sep_M&L". But I no

Creating a new thread, for a new topic, although I'm excerpting some old email as inspiration. Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is to emulate instructions. For exa

Hi Nick, John, Here's my proposal for adding two fields to the proposed MSECCFG CSR: DPL and DMC. This proposal assumes that the programming model for the permissions is sufficient without adding anot

Hi Allen, The point I was trying to make about locked PMP entries, but failed to communicate before, is this: When a system starts up after reset, PMP is enforced according to a certain set of rules.