Re: comments on PMP enhancements

Allen Baum

Two  quick comments:
- I am assuming that this is a proposal to replace the existing "enhanced" PMP proposal, rather than an "enhanced-enhanced" PMP proposal.

 - do we ever need to allow Write_Only and Write&Execute regions? OR can we continue to disallow them, except for the specific shared RW/RO regions defined by the enhanced proposal
( which in this case is when MML=1,  M=0 as opposed to the enhanced proposal of MML=1, L=0)

Separately, there is a proposal to have an S-PMP, which further filters addresses but allows Smode to configure them.
It would be useeful to consider whether they would be completely separate CSRs or they could overlay the existing ones ones somehow. 
Even if they are totally separate, it would be useful to ensure the encodings were similar enough that the same HW (with simple external wiring changes) would work for both.

On Fri, Feb 14, 2020 at 12:57 PM John Hauser <jh.riscv@...> wrote:
Nick Kossifidis wrote:
> You don't need to do a ROP attack on BootROM to remove the rules, any
> code that runs on M-mode can remove them in a few instructions. I don't
> see how we can have a security control on M mode without also locking
> the rules for preventing further modifications from the next boot
> stages.  [...]

I'd like to point out that my own proposal does always allow for the
locking of regions for the next boot stages, when that's appropriate.

> When defining security controls there are guarantees we put in place.
> Let's say that we did everything correctly, both in hw and sw, up to the
> point where we place the PMP rule there to prevent "other software"
> running on M-mode from accessing some memory region. Can we guarantee
> that this restriction will be enforced and that "other software" can't
> simply bypass it ? I don't believe we can provide such a guarantee,
> hence we can't claim this approach to be a security control. If the code
> we are trying to restrict has direct control over the security control,
> then it's not a security control, it's an ilusion of a security control.
> To the contrary it may pose a security threat.

If unlocked M-mode PMP entries can't be called security controls, then
fine, let's call them something else.  As I see it, the point is that
there is a demand/need for such an ability, it obviously involves PMP,
and furthermore it's been shown that the physical mechanisms are very
close to one another.  If you ignore this other need and adopt the
current proposal, there's a very good chance we'll end up having to
retrofit the PMP table to support this other need later, creating a
bigger mess than if we learn to accomodate it now.

I understand you're afraid that offering any compromises in the PMP
mechanism will allow developers to choose the not-totally-secure
options and delude themselves that it gives them true security.
But that's not a hardware-mechanisms problem; that's a problem for
software policies and their enforcement.  That concern needs to be
dealt with in a different way than by hobbling the hardware.

For my part, I will try to be much more careful about my use of the
words "secure" and "security" going forward.


    - John Hauser

Join to automatically receive all group messages.