1. Tech-Privileged
  2. Topics

comments on PMP enhancements

John Hauser
 

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
Jonathan Behrens <behrensj@...>
 



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

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

Regards,

    - John Hauser
John Hauser
 

Jonathan Behrens wrote:
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
Because the PMP table is explicitly searched in order for a match,
locked entries must always be at the head of the table to be truly
effective. When software wants to add a locked entry, there may be
N locked entries already in the table in positions 0 through N - 1.
If entry N is in use (not locked), it must be moved to a later position
(possibly by shifting down the entire table by one position), after
which the new locked entry can be added in position N. Usually,
software can manage the table better and avoid a lot of shifting.

Locked entries at the head of the PMP table certainly cannot be
subverted, even if entries can still be added or modified below them.

To totally lock down executable regions for M mode, at the highest
security level both the task group's working proposal and my proposal
prevent the creation of new PMP entries that grant execute permission
to M mode.

A properly configured locked PMP entry can constrain or entirely
prevent M-mode access to any memory region. In the absence of such an
entry, M mode is assumed to have authority to read/write anything it
wants, within the underlying constraints of physical memory attributes
(PMAs). Given that policy, none of the enhanced PMP proposals prevent
M mode from creating new PMP entries for itself, except as I've already
explained.

- John Hauser

1 - 3 of 3