1. Topics
  2. [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

[RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Allen Baum
 

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 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:


On Wed, Feb 19, 2020 at 3:46 PM John Hauser via Lists.Riscv.Org <jh.riscv=jhauser.us@...> 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 later

Regards,

    - John Hauser
1 - 1 of 1