[RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Allen Baum

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:

On Wed, Feb 19, 2020 at 3:46 PM John Hauser via Lists.Riscv.Org <jh.riscv=jhauser.us@...> wrote:
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 least as currently

First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode.  In
the task group's working proposal and in my proposal for four security
levels, when higher security is enabled (MML = 1 or MSL > 0), these
locked PMP entries retain their enforcement for M mode but deny all
access to S/U mode.  The M & L proposal does the opposite:  It denies
all access to M mode and gives access to S/U mode!  If an earlier
stage of boot software is unaware of the PMP extension, it might easily
create such locked entries (L = 1, M = 0), after which M mode will be
helpless to deny S/U access, or grant itself access when MML = 1.  That
looks obviously wrong to me.

Second, the M & L proposal doesn't currently offer an option to totally
lock down the executable regions for M mode, a feature touted for the
task group's working proposal and kept in my proposal with MSL = 3.  I
see no reason why this feature should be abandoned.

I believe both of these flaws can be fixed, but only at the expense of
the simple separation of the L and M bits.  In fact, you start to get a
design that looks more like my proposal.

The one feature clearly offered by the M & L proposal and not by
the other two is the ability to lock PMP entries that allow S/U-mode
access.  But on this point, I have to agree with Nick Kossifidis:  I
don't see a need for this ability.

Remind me, did all the other proposals have a way to prevent the S/U-mode entries from being reconfigured to M-mode ones later? Locking M-mode entries doesn’t do a ton if more can be added later


    - John Hauser