[RISC-V] [tech-tee] [RISC-V] [tech-privileged] Huawei review of different PMP enhancement schemes
Ø 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?
Because we can’t program the permissions we need without locking the entry, because the two functions are mixed up – changing permissions and locking, we need them to be separated. DPL is a cheap method of doing this, John Hauser’s approach is better.
Ø 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).
Yes it’s clunky but it has to reset to being disabled to match the current standard.
Ø 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?
It’s more related to the fact that we simply can’t program the permissions we need without DPL without locking the page, which is why we currently have a non-standard PMP implementation with separate RWX bits for M-mode and U-mode but we’d like to move to a standard implementation.
Ø 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".
At reset the boot vector could be hijacked through fault injection or hardware modification of the die. Having memory closed at reset (except for a small section of the boot ROM) is required to prevent this attack method, so that the core can ONLY boot from the boot ROM. To achieve this without DMC then we need to reset the highest numbered entry to cover all of memory with no access and burn a PMP entry to do it. So we need this in place at reset.
Tariq
Sent: 24 February 2020 23:50
To: John Hauser <jh.riscv@...>
Cc: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] Huawei review of different PMP enhancement schemes
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