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