Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements
You need to be careful with terminology. I am assuming that
"denying access to Mmode" means
"denying the ability of M-mode to change an entry" , and not
"denying the ability of M-mode to change an entry" , and not
"denying access to the region defined by an entry".
But: if an entry is created (necessarily by M-mode) that is locked and such that M-mode can no longer touch that region but S/U mode can - that is either intentional or that M-mode code is buggy, in my opinion. And, even if that happens, M-mode code code always define an unlocked region of higher priority (unless it has allocated all the higher priority regions). Again, intentional or buggy M-mode code. We can't defend against stupid buggy code.
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.
A region which is intended to be executable (by Mmode only) can be made as L-RX, so that code can no longer be altered, and when MM is set to 1 only Mmode code can execute it.
That's not much different than the separate M+L. I thought the reason for separate M+L was to give the ability to have unlocked unwritable regions that were inaccessible to S/U mode (so the M-mode region could be expanded without requiring using new entries).
IF you didn't care about the unwritability, you can do this with the current enhanced proposal.
There are a lot of hidden assumptions about the use model here, e.g. is it permitted to leave M-mode before the final (locked) M-mode configuration has been set up?
If not (and I'd like to know why that isn't a reasonable assumption) then separate M+L seems a bit less important.
Could you give me a more complete example where the current enhanced proposal doesn't do what you want?
On Wed, Feb 19, 2020 at 1:15 PM Jonathan Behrens <behrensj@...> 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 laterRegards,
- John Hauser