Re: comments on PMP enhancements

Jonathan Behrens <behrensj@...>

On Wed, Feb 19, 2020 at 3:46 PM John Hauser via Lists.Riscv.Org <> 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

Join to automatically receive all group messages.