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
designed:

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.

Regards,

- John Hauser