Hello John,

Στις 2020-02-14 22:56, John Hauser έγραψε:
>
> 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.
>

So does the original PMP spec and the group's proposal.

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

There are people already using PMP as-is in production, providing TEE
and secure boot mechanisms (e.g. multizone and keystone) without needing
the ability to have removable / editable rules on M-mode. For 1+ year
that we've been working on this proposal to improve PMP so that it can
also be used to provide access / execution prevention from M-mode, we've
only heard of such a requirement from Huawei so that the PMP spec
matches their solution. I'm not against incorporating such a feature,
all I want is to make sure it's there for the right reasons and that
it's defined properly. On one hand I get your point that we need to be
as flexible as possible, on the other hand we can't please everyone,
especially by making an already established security control weaker.
RISC-V already allows for vendors to implement their own PMP mechanism
anyway and vendors will do that regardless of the PMP spec, the proposed
mseccfg CSR may make this even easier / cleaner to do so e.g. by having
vendor-specific fields there in the future. Where do we put the line
between a spec that provides a set of security guarantees, and allowing
for that spec to be weaker for flexibility ?

At least in Huawei's case what they want can be integrated to the
group's proposal (or even the current PMP spec since it's independent of
MML) easily, and hopefully without compromising security if defined /
used properly. What happens if a vendor asks for something that allows
e.g. for a security control to be completely bypassed (e.g. disable
SMEP), or for an insecure crypto algorithm to be added on one of our
specs, or for a security mechanism that's not secure at all ? Will we go
for flexibility or for security ?

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

When a system gets compromised it's everyone's problem. It's not a
matter of having or not having a hw mechanism, it's a matter of properly
defining what's the goal of this mechanism and its scope. If we say for
example that a region is "protected by PMP" when on M-mode, and the
corresponding rule can be removed / edited by M-mode at any time, in a
few instructions, then we will be lying. If the spec is not absolutely
clear on how a security mechanism works and under which conditions it
provides security guarantees, things will go wrong. It has happened many
times in the past where people created specs or products that allowed
for less-secure (or even totally insecure) configurations to be used.

Regards,
Nick