Στις 2020-02-14 22:56, John Hauser έγραψε:
I'd like to point out that my own proposal does always allow for theSo does the original PMP spec and the group's proposal.
If unlocked M-mode PMP entries can't be called security controls, thenThere 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 PMPWhen 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.