Huawei review of different PMP enhancement schemes
|
Mr Tariq Kurd <tariq.kurd@...>
Hi everyone,
We have spent a considerable amount of time reviewing the different proposals and have come to some conclusions.
1. The PMP enhancement proposal can meet our needs with the following modifications - DMC (default memory closed) - DPL (delay PMP locking) - Shared executable regions --> This feature is missing from all the proposals except for the separate M&L proposal,
I've attached another modified version of the PMP enhancement proposal, this time including shared X/X RX/X regions in the reserved programming encodings (and changed the name of the document to include “shared X”)
We want this to save code size, so we can share (e.g.) the C runtime library between the OS and application code.
Allen - I think that the "any region locked" proposal doesn't work for us, because we want to be able to remove access to any unmapped memory without locking a region. Sorry, it’s a nice idea.
Joe - The suggestion of running code in U-mode during the boot process to avoid locking regions when MML=1 is interesting, and certainly possible. However it's a lot more work to set up a handler and system calls back to the handler - it's like a light OS just for the boot process. DPL to delay the locking is a much simpler solution.
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).
When MSL = 1, 2 or 3 and RWX=W -> shared region with X permission When MSL = 1, 2 or 3 and RWX=WX -> shared region with M-mode RX and S/U-mode X permission
This approach gives us the choice of whether to lock the regions or not, which is good although we think that locked shared X regions are probably sufficient.
3. Separate M&L doesn't offer many benefits - it was a simple proposal to see what would happen by separating out the bits. - it naturally has shared executable regions
In summary
- PMP enhancement + DPL + DMC + shared X is ok for us - John’s 4-level scheme + shared X is better for us
Tariq
PS if we do develop John proposal further then we think there are some corner cases to resolve - we think that the programming model is a bit strange because some of the configuration bits become read-only at different times, which is not good for software which will try to program a configuration and then quietly get a different configuration
The two obvious examples are - trying to program PL=1 or 3 when MSL=0 - trying to program an X region when MSL=3 I think in these cases PL[0] is ignored and the X bit is ignored respectively when writing the configuration. We would prefer to have an exception to say that the software programming the PMP is clearly wrong, to give us a chance to debug it.
-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of John Hauser Sent: 22 February 2020 01:19 To: tech-tee@...; tech-privileged@... Subject: Re: [RISC-V] [tech-tee] comments on PMP enhancements
Hi Allen,
The point I was trying to make about locked PMP entries, but failed to communicate before, is this:
When a system starts up after reset, PMP is enforced according to a certain set of rules. For two of the proposals, the initial rules (MML = 0 or MSL = 0) are the same as currently standardized. For Mr. Kurd's separate M & L proposal, when MML = 0, entries created with M = 0 follow the currently standardized rules as they should.
After reset, an early stage of boot software might create a locked PMP entry under the initial PMP rules, intending to restrict M-mode's access to a certain region of memory. The early boot stage might be oblivious to the PMP enhancements or (perhaps more likely) it might want to be compatible with later boot stages that may or may not be aware of the PMP enhancements.
If a later stage then raises the level of PMP security by setting MML = 1 or MSL > 0, existing PMP entries are now enforced according to a new set of rules. For two of the proposals, the new rule for an existing locked entry is that S/U mode has no access and M mode has restricted access. But for Mr. Kurd's separate M & L proposal, the new rule is that S/U mode gets restricted access and M mode gets _no_ access. This is what I find questionable. The original intention under the initial rules was almost surely to give M mode restricted access, which has now been revoked. And the worst part is, although M mode itself no longer has access, it cannot deny access to S/U mode, because the entry is locked.
Here's what happens, step by step:
1. Machine starts from reset.
2. Early boot stage creates a locked PMP entry under initial PMP rules, intending to restrict M mode's access to memory.
3. Subsequent boot stage enables PMP enhancement, by setting MML = 1 (or MSL > 0).
Under the separate M & L proposal, at this point M mode has _no_ access to the memory covered by the PMP entry created in step 2, but S/U mode _does_ have access. And this situation is unchangeable because the entry is locked.
Under the task group's working proposal or my four-security-level proposal, M mode still has restricted access. It is S/U mode that loses access. I argue that this is better, and the separate M & L proposal is "wrong" on this point.
On a different topic, I wrote: > Mr. Kurd's proposal does not similarly lock down all of M mode's > executable regions against modification nor prevent the creation of > new PMP entries for executable regions. That is the shortcoming to > which I was referring.
You: > Well, that would be a pretty simple modification of his proposal, then: > disallow creation of new Mode X regions when MML=1. > If that modification was made, what drawbacks remain?
Preventing the creation of new regions with execute permission is only one piece of the lockdown of M-mode executable regions. The other is to lock all existing PMP entries that give M mode execute permission, so their address ranges can't be modified. The task group's working proposal does that by locking all M-mode-only PMP entries, something I replicated in my topmost security level, MSL = 3. Currently, the separate M & L proposal doesn't do this piece either.
Here's what I wrote before about both shortcomings I identified in the separate M & L proposal:
> I believe both of these flaws can be fixed, but only at the expense of > the simple separation of the L and M bits. In fact, you start to get > a design that looks more like my proposal.
And that's what I want to emphasize: Why patch a proposal with several tweaks when, as I see it, there is another, cleaner proposal on hand that already covers all the same needs?
You: > I'd still like to simplify either proposal by removing DMC and > replacing it with "any entry locked". > Once you've locked a region, there is no need to access unmapped > regions, since you can do that from the locked region
That's conceivable, but has the disadvantage of sometimes requiring one or more additional PMP entries. Thus, your desire to save one flip-flop and a few gates for DMC could sometimes cost 40 or 50 flip-flops and corresponding logic to have at least one more PMP entry. My own assessment is that, in any RISC-V core that implements standard PMP, that one flip-flop and small bit of logic is not worth fretting over.
Regards,
- John Hauser
|
|
|
