Date 1 - 1 of 1
comments on PMP enhancements
|1 - 1 of 1|
Second, the M & L proposal doesn't currently offer an option to totallyAllen Baum:
I also don't see why M&L (I assume you mean the current enhanced proposal)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
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
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
- John Hauser
|1 - 1 of 1|