1. Messages
  2. Huawei review of different PMP enhancement schemes

Re: Huawei review of different PMP enhancement schemes

Allen Baum
 

Just as I have been asking why DMC is necessary, I have to ask why the DPL bit is necessary.
If there is code that wants to reorder PMP entries while DPL is 1, but the lock bits are set - why don't you instead simply not program any lock bits until you get to the point that you would have changed DPL from 1->0? As the doc mentions: It is noted that this style of boot flow does not prevent the PMP being unlocked again by software, and so the security is lower than if the regions remain locked.
If  you are executing code that has not been authenticated while existing entries are unlocked (or the L bit is set but hasn't taken effect) - then you have a security issue.
The DPL bit doesn't fix that, therefore it seems to me that the sequence above (separate "lock everything that needs locking" phase) gives you equivalent security.
Also note that DPL is really two bits when implemented, since it as 3 states (initially 0, has been set to 1, has transitioned to 0 and is now locked).

Can someone show a sequence that has higher security with DPL compared to a sequence that sets all the lock bits at the point that DPL would have been cleared?
Ditto for DMC: can someone show a sequence (and memory map) that causes an extra entry to be required if the default memory closed is defined as "any entry is locked".
If someone doesn't demonstrate one (that can't be easily modified to avoid the problem with equivalent security), I can't support either.

On Mon, Feb 24, 2020 at 2:09 PM John Hauser <jh.riscv@...> wrote:
Tariq Kurd wrote:
> 2. John Hauser's proposal is better than (1)
>
> - the programming model is simpler - it's hard to get my head around
>   the state changes when setting MML=1, but it's easier to follow
>   John's
>
> - the modes cover what we need to do
>
> --> Shared executable regions are still missing - I think we also
> need to use the W and WX permissions as the PMP enhancement proposal
> does (it's not clear if these are reserved or not - they are reserved
> in the spreadsheet but not in the document).

Hi Tariq,

I meant for the encodings with W = 1 and R = 0 to continue to be
reserved, as the spreadsheet indicates, but you're right that I forgot
to say so in my document.

I have a different suggestion for adding support for shared executable
regions.  I've attached a new spreadsheet file with a new tab showing
my upgraded proposal, version 0.3.  You can easily see the changes
by switching between the tabs labeled "4level 0.2" and "4level 0.3".
In my newest version, PMP entries with PL = 0, W = 0, and X = 1
(executable but not writable in S/U mode) are now readable/executable
in M mode.  Previously all entries with PL = 0 were readable/writable
for M mode.

When MSL = 3, all PMP entries that give execute permission to M mode
are locked.  And new entries that would give execute permission to
M mode cannot be created when MSL = 3, the same as before.

I haven't updated my document yet, but I thought we could debate my
version 0.3 just from the spreadsheet.

I look forward to all feedback.

    - John Hauser
Join tech-privileged@lists.riscv.org to automatically receive all group messages.