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