Re: comments on PMP enhancements

John Hauser

I wrote:
The case that needs to be dealt with is an S/U-mode-only region that
is execute-only, without read permission. [...]
Bill Huffman:
On one level, I agree with John here. But MXR and MPRV were set up when
M mode never had less permission than S/U. I'm not sure I understand
current behavior when the PMP entry is locked with execute-only
permission (which applies to M as well as S/U) and MXR is set. Does
that make M mode able to read instructions even though M mode itself
couldn't otherwise read them? That seems to me to reduce the meaning of
execute-only to something less than execute-only.
To answer your question, for current standard PMP, when a PMP entry
makes a region execute-only for all modes, MXR does not make reading
possible from any mode, because MXR is currently defined only to modify
page table permissions, not PMP. I wasn't proposing to allow M mode to
read from its own execute-only regions, nor S/U mode to read from its
own execute-only regions. No existing or proposed rule for MXR allows

However... Now that you've pushed me to look at this once again, I've
realized a flaw in my MXR proposal that I missed before. The upshot is
that I withdraw my demand for a special case for handling MXR. Anyone
interested in the reason why can read on.

The current standard allows a PMP entry to define a region that is
execute-only for S/U mode but with full access for M mode. What I
overlooked earlier is that MXR doesn't let M mode read that memory when
MPRV = 1 and MPP = 0 or 1. So the problem I wanted to solve exists
already; execute-only regions for S/U mode can already be trouble if
any instructions need to be emulated in M mode.

I guess the correct answer is that M mode shouldn't configure
execute-only regions for S/U mode unless it's prepared to deal with
this, which in practice probably means it needs to know ahead of time
that no instructions in the region require emulation. If that's
considered an adequate resolution, it can apply also to any S/U-mode-
only regions that are execute-only, which is the case I was pursuing.
On the other hand, on the chance it's not considered adequate, then any
changes made to how MXR, MPRV, and PMP interact ought to be addressed
separately from the PMP enhancement proposal. The two issues should be
considered orthogonal.

Sorry about the distraction.

I tend to think the broader view is good. Otherwise we'll get contorted
bits here (sooner than we otherwise would :-) ). Locking mtvec seems
like it might be related. To me, even though it's, in some ways a
separate proposal, understanding the level of security provided should
include as many aspects as possible. Otherwise we may find when we get
to mtvec we didn't consider something.
I don't object to everything being looked at before committing to any
security extensions. But I got the impression there may be some who
hope to elevate the task group's current proposal ASAP.

- John Hauser

Join to automatically receive all group messages.