I wrote:

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.

Allen Baum:

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

By the "M & L proposal" I meant Tariq Kurd's proposal, the one I was
speaking of. (On your own cheat sheet from yesterday, the tab for this
proposal is labeled "sep_M&L". But I now see that the word "separate"
is a crucial part of your labelling, whereas I thought it could just be
implied.)

Anyway, getting back to the point, in the task group's document, part
3(b) of the proposal says that when MML = 1,

Adding a new PMP rule with pmpcfg.L and pmpcfg.X bits is not
possible and such pmpcfg writes are ignored, leaving pmpcfg
unchanged.

This goes beyond the ability to create a locked PMP entry; it
independently _prevents_ the ability to create new entries of the type
specified. The rationale for this is in the document's "Rationale"
section, where it is briefly explained that this limits the attack
surface as much as possible.

My own four-security-level proposal duplicates this rule in section 2.4:

In addition, level 3 prevents the configuration of new locked PMP
entries that give execute permission to M mode (PL = 2 or 3, with
bit X = 1). An attempt to configure such an entry is ignored.

Replicating this condition is in fact the _only reason_ my proposal
needs the topmost security setting, MSL = 3.

Mr. Kurd's proposal does not similarly lock down all of M mode's
executable regions against modification nor prevent the creation of new
PMP entries for executable regions. That is the shortcoming to which I
was referring.

- John Hauser