|
On Thu, Oct 14, 2021 at 2:11 PM Aaron Durbin < adurbin@...> wrote:
Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?
Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
Apologies for being tardy. The following link is a description of what we were thinking for the purposes of a simple way to protect machine mode memory. It's obviously not perfect, but we would appreciate any feedback. After the initial round of feedback we can clean up the language, change it to asciidoc, etc and send it to priv list. But we were hoping for a healthy discussion prior to all of that.
If people would prefer I distill it into asciidoc first and send a pull request somewhere, I'm perfectly fine doing that. Please let me know as I want to accommodate the best way for interaction.
Thank you.
-Aaron
|
|
|
mark
+security -------- sent from a mobile device. please forgive any typos.
On Oct 20, 2021, at 4:19 PM, Aaron Durbin <adurbin@...> wrote:
On Thu, Oct 14, 2021 at 2:11 PM Aaron Durbin < adurbin@...> wrote:
Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?
Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
Apologies for being tardy. The following link is a description of what we were thinking for the purposes of a simple way to protect machine mode memory. It's obviously not perfect, but we would appreciate any feedback. After the initial round of feedback we can clean up the language, change it to asciidoc, etc and send it to priv list. But we were hoping for a healthy discussion prior to all of that.
If people would prefer I distill it into asciidoc first and send a pull request somewhere, I'm perfectly fine doing that. Please let me know as I want to accommodate the best way for interaction.
Thank you.
-Aaron
|
|
|
Aaron,
Given that this is an ISA extension proposal, it isn't in the domain of profile or platform specs (or the Platforms group), and should be directed to the appropriate TG, SIG, or IC/HC. In this case (and reflecting Mark's cc of the Security HC) it seems like this should go to the Security HC and/or the TEE TG. Ultimately creating a TG to pursue taking this through the process to become a ratified standard falls under the governance of an IC/HC. But for the sake of stimulating initial discussions, I would imagine the Security HC, TEE TG, and Priv IC email lists are good venues to post this to.
To clarify my first sentence, ratified profiles and platforms only get to refer to ratified ISA and Non-ISA standards; they don't get to create new standards. A working spec can refer to standards that are also in the works, but ultimately each milestone for a profile or platform spec can't get ahead of the corresponding milestone for standards being referenced.
Greg
On Wed, Oct 20, 2021 at 4:19 PM Aaron Durbin < adurbin@...> wrote: On Thu, Oct 14, 2021 at 2:11 PM Aaron Durbin < adurbin@...> wrote:
Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?
Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
Apologies for being tardy. The following link is a description of what we were thinking for the purposes of a simple way to protect machine mode memory. It's obviously not perfect, but we would appreciate any feedback. After the initial round of feedback we can clean up the language, change it to asciidoc, etc and send it to priv list. But we were hoping for a healthy discussion prior to all of that.
If people would prefer I distill it into asciidoc first and send a pull request somewhere, I'm perfectly fine doing that. Please let me know as I want to accommodate the best way for interaction.
Thank you.
-Aaron
|
|
|
On Wed, Oct 20, 2021 at 6:38 PM Greg Favor < gfavor@...> wrote: Aaron,
Given that this is an ISA extension proposal, it isn't in the domain of profile or platform specs (or the Platforms group), and should be directed to the appropriate TG, SIG, or IC/HC. In this case (and reflecting Mark's cc of the Security HC) it seems like this should go to the Security HC and/or the TEE TG. Ultimately creating a TG to pursue taking this through the process to become a ratified standard falls under the governance of an IC/HC. But for the sake of stimulating initial discussions, I would imagine the Security HC, TEE TG, and Priv IC email lists are good venues to post this to.
Understood. I was sending it to this list because Jonathan had asked about it, and it was related to the discussion. I wasn't trying to formally propose anything just yet -- was looking for a continuation of the discussion. When the time comes I can move to those other appropriate avenues.
To clarify my first sentence, ratified profiles and platforms only get to refer to ratified ISA and Non-ISA standards; they don't get to create new standards. A working spec can refer to standards that are also in the works, but ultimately each milestone for a profile or platform spec can't get ahead of the corresponding milestone for standards being referenced.
Greg On Wed, Oct 20, 2021 at 4:19 PM Aaron Durbin < adurbin@...> wrote: On Thu, Oct 14, 2021 at 2:11 PM Aaron Durbin < adurbin@...> wrote:
Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?
Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
Apologies for being tardy. The following link is a description of what we were thinking for the purposes of a simple way to protect machine mode memory. It's obviously not perfect, but we would appreciate any feedback. After the initial round of feedback we can clean up the language, change it to asciidoc, etc and send it to priv list. But we were hoping for a healthy discussion prior to all of that.
If people would prefer I distill it into asciidoc first and send a pull request somewhere, I'm perfectly fine doing that. Please let me know as I want to accommodate the best way for interaction.
Thank you.
-Aaron
|
|
|
Anup Patel
On Thu, Oct 21, 2021 at 4:49 AM Aaron Durbin <adurbin@...> wrote:
On Thu, Oct 14, 2021 at 2:11 PM Aaron Durbin <adurbin@...> wrote:
Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?
Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
Apologies for being tardy. The following link is a description of what we were thinking for the purposes of a simple way to protect machine mode memory. It's obviously not perfect, but we would appreciate any feedback. After the initial round of feedback we can clean up the language, change it to asciidoc, etc and send it to priv list. But we were hoping for a healthy discussion prior to all of that.
https://docs.google.com/document/d/1CIMlkr-IQUeCSa46mZEwVSHmluH9qAD52WW3SMg_urc/edit?usp=sharing
If people would prefer I distill it into asciidoc first and send a pull request somewhere, I'm perfectly fine doing that. Please let me know as I want to accommodate the best way for interaction.
First feedback I have on this new proposal is that it only provides range registers for M-mode code and data for each HART. We also have M-mode devices (such as ACLINT MTIMER, ACLINT MSWI, IMSIC M-files, etc) which need to be protected from S-mode and U-mode software. We will need more range register pairs for each HART to protect all M-mode assets. Regards, Anup
Thank you.
-Aaron
|
|
|
On Wed, Oct 20, 2021 at 10:17 PM Anup Patel < anup@...> wrote: On Thu, Oct 21, 2021 at 4:49 AM Aaron Durbin <adurbin@...> wrote:
>
> On Thu, Oct 14, 2021 at 2:11 PM Aaron Durbin <adurbin@...> wrote:
>>>
>>>
>>> Out of curiosity, do you have a system you're designing that uses a custom alternative to PMP?
>>
>>
>> Yes, we have an internal doc, and we intend to provide a proposal for a simpler way of protecting m-mode assets. We hope to get that out soon (either end of the week or early next).
>
>
> Apologies for being tardy. The following link is a description of what we were thinking for the purposes of a simple way to protect machine mode memory. It's obviously not perfect, but we would appreciate any feedback. After the initial round of feedback we can clean up the language, change it to asciidoc, etc and send it to priv list. But we were hoping for a healthy discussion prior to all of that.
>
> https://docs.google.com/document/d/1CIMlkr-IQUeCSa46mZEwVSHmluH9qAD52WW3SMg_urc/edit?usp=sharing
>
> If people would prefer I distill it into asciidoc first and send a pull request somewhere, I'm perfectly fine doing that. Please let me know as I want to accommodate the best way for interaction.
First feedback I have on this new proposal is that it only provides
range registers for M-mode code and data for each HART. We also have
M-mode devices (such as ACLINT MTIMER, ACLINT MSWI, IMSIC M-files,
etc) which need to be protected from S-mode and U-mode software. We
will need more range register pairs for each HART to protect all
M-mode assets.
That is correct. It takes a stance on the hart aspect as well as I/O agents w.r.t. machine mode memory, but it doesn't prescribe a way to control access to other assets that reside within the physical address space. Protection of MMIO can be accomplished in different ways. e.g. every agent that issues a transaction can encode the source on the hypothetical fabric/interconnect. Access control can be enforced using the issuing agent w.r.t. register endpoints. We aren't suggesting every implementer would want to go this route, but protection can certainly be achieved in this manner.
Regards,
Anup
>
> Thank you.
>
> -Aaron
|
|
|
I'd guess access to the machine mode code and data from virtualization mode (V=1) is also denied, perhaps this should be explicitly stated.
Also I prefer to deny loads from the MCRR range under machine mode. This would make code leak more difficult, leaked binary makes it easier to pick gadgets to launch a code reuse attack.
|
|
|
I'd guess access to the machine mode code and data from virtualization mode (V=1) is also denied, perhaps this should be explicitly stated.
Sure, I can make it more explicit in that case.
Also I prefer to deny loads from the MCRR range under machine mode. This would make code leak more difficult, leaked binary makes it easier to pick gadgets to launch a code reuse attack.
While that is certainly possible, I would then be more concerned about this scenario: read-only data. That typically would live within the code area, but if loads couldn't be done to the MCRR then one would have to move the read-only data into the data area making it writable.
|
|
|
If I understand correctly, it seems like ePMP provides close (but maybe not exactly?) to what you want, e.g. you can have M-mode-only Rd-Only, Rd-Wr, and Rd-Exec regions. And one can have a lower-priority rule that gives S/U modes access to all or however much address space (minus the M-mode-only holes). Further, for any "shared" regions between M-mode and S/U modes, one can have regions covering those with suitable access restrictions.
|
|
|
On 10/22/21 9:32 AM, Aaron Durbin
wrote:
I'd guess access to the
machine mode code and data from virtualization mode (V=1) is
also denied, perhaps this should be explicitly stated.
Sure, I can make it more explicit in that case.
Also I prefer to deny loads from the MCRR range under
machine mode. This would make code leak more difficult,
leaked binary makes it easier to pick gadgets to launch a
code reuse attack.
While that is certainly possible, I would then be more
concerned about this scenario: read-only data. That
typically would live within the code area, but if loads
couldn't be done to the MCRR then one would have to move the
read-only data into the data area making it writable.
Code has to be executing in M-mode itself to be able to read the
MCRR.
For all other modes the MCRR memory is denied.
So is the premise that malicious code execution privilege has
already been obtained in m-mode so that the maliciously code can
further read its own binary to do further attacks?
regards
ved
|
|
|
On Fri, Oct 22, 2021 at 1:52 PM Vedvyas Shanbhogue < ved@...> wrote:
So is the premise that malicious code execution privilege has
already been obtained in m-mode so that the maliciously code can
further read its own binary to do further attacks?
This is what security people love to hear, so they can then go to work and show how wrong us hardware architects and designers are with what we imagine to be possible and not possible (sometimes with amazing ingenuity that we wouldn't imagine being possible). Just look at some of the more recent side-channel attacks.
Two general principles of security guys is that 1) a security breach of whatever defenses one has is only a matter of when, not if, and 2) reducing attack surface and reducing breach impact are important. Disallowing reading of code falls in the latter category.
Greg
|
|
|
On 10/22/21 5:18 PM, Greg Favor wrote:
On Fri, Oct 22, 2021 at 1:52 PM Vedvyas
Shanbhogue < ved@...> wrote:
So is the premise that malicious code execution
privilege has already been obtained in m-mode so that
the maliciously code can further read its own binary to
do further attacks?
This is what security people love to hear, so they can
then go to work and show how wrong us hardware architects
and designers are with what we imagine to be possible and
not possible (sometimes with amazing ingenuity that we
wouldn't imagine being possible). Just look at some of the
more recent side-channel attacks.
I was asking a question to clarify the premise.
Two general principles of security guys is that 1) a
security breach of whatever defenses one has is only a
matter of when, not if, and 2) reducing attack surface and
reducing breach impact are important. Disallowing reading
of code falls in the latter category.
So I am trying to understand the threat model.. Reading of code
by who?
regards
vedvyas
|
|
|
My response admittedly was at a general level - since I'm far from one of those super-ingenious security guys that figures out how to attack basic defenses like this. But presupposing that a certain defense (like this simplified PMP arch) is unbreachable is often dangerous even though we can't imagine how an attack could be performed.
As far as who would be reading the code, one maybe uses existing loads in the code to do the dirty work (effectively as gadgets) and uses SCA-style techniques to convert speculative load accesses into discoverable values. (Again, I'm not trying to describe how an attack could actually be performed. This is just mentioning a couple of the types of tools in security guys' tool boxes.)
As a side note, the point of ePMP is to provide PMP mechanisms to protect M-mode code from itself (meaning protect some parts of M-mode from other parts that may be breached or may be less trusted).
So all I can say is "beware". The past 5-10 years is rife with amazingly ingenious attacks of seemingly strongly protected code. Sorry for that most likely being an unsatisfying answer. Security guys are the ones to provide more satisfying answers.
But it is also fair to say that any given design has to decide how far it will go in hardening itself against attacks. For some designs allowing reading of the code is maybe OK.
Greg
On Fri, Oct 22, 2021 at 3:26 PM Vedvyas Shanbhogue < ved@...> wrote:
On 10/22/21 5:18 PM, Greg Favor wrote:
On Fri, Oct 22, 2021 at 1:52 PM Vedvyas
Shanbhogue < ved@...> wrote:
So is the premise that malicious code execution
privilege has already been obtained in m-mode so that
the maliciously code can further read its own binary to
do further attacks?
This is what security people love to hear, so they can
then go to work and show how wrong us hardware architects
and designers are with what we imagine to be possible and
not possible (sometimes with amazing ingenuity that we
wouldn't imagine being possible). Just look at some of the
more recent side-channel attacks.
I was asking a question to clarify the premise.
Two general principles of security guys is that 1) a
security breach of whatever defenses one has is only a
matter of when, not if, and 2) reducing attack surface and
reducing breach impact are important. Disallowing reading
of code falls in the latter category.
So I am trying to understand the threat model.. Reading of code
by who?
regards
vedvyas
|
|
|
I agree with you about that and I am all for defence in depth. For
that reason I am also opposed to the idea that read-only data could
exist in MCRR as that itself is also problematic.
That's what I wanted to clarify that it is m-mode itself which has
been setup to reveal its code.
There are few ways I can think it can be done:
1. You could have a memcpy routing in m-mode code and you may be able
to influence the source address of the memcpy
2. You could have a meltdown or L1TF like issue that allows you to
breach and access the contents of the range even when executing
outside M-mode
3. You could have a speculative execution vulnerability that lets you
transiently read the code and expose it through a side channel
4. Or some other means.
Making the MCRR not readable will address the cases where M-mode
itself is tricked into reading and revealing it.
If there is a SCA type bug that violates the access controls then that
is likely not to be prevented.
regards
ved
toggle quoted message
Show quoted text
On Fri, Oct 22, 2021 at 5:56 PM Greg Favor <gfavor@...> wrote:
My response admittedly was at a general level - since I'm far from one of those super-ingenious security guys that figures out how to attack basic defenses like this. But presupposing that a certain defense (like this simplified PMP arch) is unbreachable is often dangerous even though we can't imagine how an attack could be performed.
As far as who would be reading the code, one maybe uses existing loads in the code to do the dirty work (effectively as gadgets) and uses SCA-style techniques to convert speculative load accesses into discoverable values. (Again, I'm not trying to describe how an attack could actually be performed. This is just mentioning a couple of the types of tools in security guys' tool boxes.)
As a side note, the point of ePMP is to provide PMP mechanisms to protect M-mode code from itself (meaning protect some parts of M-mode from other parts that may be breached or may be less trusted).
So all I can say is "beware". The past 5-10 years is rife with amazingly ingenious attacks of seemingly strongly protected code. Sorry for that most likely being an unsatisfying answer. Security guys are the ones to provide more satisfying answers.
But it is also fair to say that any given design has to decide how far it will go in hardening itself against attacks. For some designs allowing reading of the code is maybe OK.
Greg
On Fri, Oct 22, 2021 at 3:26 PM Vedvyas Shanbhogue <ved@...> wrote:
On 10/22/21 5:18 PM, Greg Favor wrote:
On Fri, Oct 22, 2021 at 1:52 PM Vedvyas Shanbhogue <ved@...> wrote:
So is the premise that malicious code execution privilege has already been obtained in m-mode so that the maliciously code can further read its own binary to do further attacks?
This is what security people love to hear, so they can then go to work and show how wrong us hardware architects and designers are with what we imagine to be possible and not possible (sometimes with amazing ingenuity that we wouldn't imagine being possible). Just look at some of the more recent side-channel attacks.
I was asking a question to clarify the premise.
Two general principles of security guys is that 1) a security breach of whatever defenses one has is only a matter of when, not if, and 2) reducing attack surface and reducing breach impact are important. Disallowing reading of code falls in the latter category.
So I am trying to understand the threat model.. Reading of code by who?
regards
vedvyas
|
|
|
On Fri, Oct 22, 2021 at 11:01 AM Greg Favor < gfavor@...> wrote: If I understand correctly, it seems like ePMP provides close (but maybe not exactly?) to what you want, e.g. you can have M-mode-only Rd-Only, Rd-Wr, and Rd-Exec regions. And one can have a lower-priority rule that gives S/U modes access to all or however much address space (minus the M-mode-only holes). Further, for any "shared" regions between M-mode and S/U modes, one can have regions covering those with suitable access restrictions.
From a property standpoint for various regions you could view it analogously. From the other rules associated with [e]PMP one has to cover the entirety of the address space with [e]PMP entries to grant permissions since S/U has no permissions by default when utilizing [e]PMP.
These quotes are from the PMP section of priv spec: "In effect, PMP can grant permissions to S and U modes, which by default have none, and can revoke permissions from M-mode, which by default has full permissions." "If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an S-mode or U-mode access, but at least one PMP entry is implemented, the access fails."
-Aaron
|
|
|
In that case, the read-only data needs its own section. There are a few bits still available in the MCRR CSR, perhaps they can be used to encode fixed-length regions that immediately follows the code section which is the read-only section. For (a sketchy) example:
MCRR[2:0] can be used to encode a number from zero to seven inclusive, then the read-only region is the region that immediately follows the code section, its size is 2^(8 + MCRR[2:0]). The last byte of the code section needs some careful treatment. That gives a read-only section of size from 256 bytes to 32K bytes, which could be sufficient for really simple systems.
|
|
|
In that case, the read-only data needs its own section. There are a few bits still available in the MCRR CSR, perhaps they can be used to encode fixed-length regions that immediately follows the code section which is the read-only section. For (a sketchy) example:
MCRR[2:0] can be used to encode a number from zero to seven inclusive, then the read-only region is the region that immediately follows the code section, its size is 2^(8 + MCRR[2:0]). The last byte of the code section needs some careful treatment. That gives a read-only section of size from 256 bytes to 32K bytes, which could be sufficient for really simple systems.
Siqi, I agree that if we want to protect read-only regions that are purefly for data consumption we'll need to handle that in a specific way. Thanks for the suggestion as a way to make that happen.
I personally wish machine mode had paging as that'd make things more flexible w.r.t. layering attributes over the physical address space. It's obviously not there now, but it would make such approaches easier.
|
|
|
Allen Baum
If you want security, adding paging to Mmode is not the approach you want to take. That's a backwards step. You don't want mapping, you want protection, and that's what this proposal, and PMPs provide. The real difference is that this proposal defines the Mmode regions that should be denied to S/U, instead of regions that are allowed to S/U modes.
I'm not sure there is much here that the ePMP proposal doesn't already cover, though. That is, implementing 2 ePMP registers will give you the same protections as 2 *pairs* of base/mask registers. The ePMP proposal is not that complicated, especially if you're trying to achieve the limited functionality defined here, because many fields and control bits can be hardwired.
I'd be interested to hear why you think this is so much simpler than ePMP. The IO control is a separate issue, and I don't know if the IOPMP proposal is simple enough for you.
On Wed, Oct 27, 2021 at 8:56 AM Aaron Durbin < adurbin@...> wrote:
In that case, the read-only data needs its own section. There are a few bits still available in the MCRR CSR, perhaps they can be used to encode fixed-length regions that immediately follows the code section which is the read-only section. For (a sketchy) example:
MCRR[2:0] can be used to encode a number from zero to seven inclusive, then the read-only region is the region that immediately follows the code section, its size is 2^(8 + MCRR[2:0]). The last byte of the code section needs some careful treatment. That gives a read-only section of size from 256 bytes to 32K bytes, which could be sufficient for really simple systems.
Siqi, I agree that if we want to protect read-only regions that are purefly for data consumption we'll need to handle that in a specific way. Thanks for the suggestion as a way to make that happen.
I personally wish machine mode had paging as that'd make things more flexible w.r.t. layering attributes over the physical address space. It's obviously not there now, but it would make such approaches easier.
|
|
|
If you want security, adding paging to Mmode is not the approach you want to take. That's a backwards step. You don't want mapping, you want protection, and that's what this proposal, and PMPs provide.
My parting comment was on layering attributes over the physical address space protections -- e.g. read-only data. Nothing more. The real difference is that this proposal defines the Mmode regions that should be denied to S/U, instead of regions that are allowed to S/U modes.
I'm not sure there is much here that the ePMP proposal doesn't already cover, though. That is, implementing 2 ePMP registers will give you the same protections as 2 *pairs* of base/mask registers. The ePMP proposal is not that complicated, especially if you're trying to achieve the limited functionality defined here, because many fields and control bits can be hardwired.
I'd be interested to hear why you think this is so much simpler than ePMP. The IO control is a separate issue, and I don't know if the IOPMP proposal is simple enough for you.
It is my understanding that ePMP introduces the changes where mseccfg.MML changes the behavior of .L field in the PMP entries to mean L=1 machine mode and L=0 S/U for physical address space protection. While it does allow making a distinction between M and S/U regions, it doesn't change the default matching rules. As noted up thread:
"In effect, PMP can grant permissions to S and U modes, which by default have none, and can revoke permissions from M-mode, which by default has full permissions." "If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an S-mode or U-mode access, but at least one PMP entry is implemented, the access fails."
Therefore, one has to carve out S/U access for the entirety of the physical address space. Perhaps I missed the rules for matching being changed in the ePMP proposal?
On Wed, Oct 27, 2021 at 8:56 AM Aaron Durbin < adurbin@...> wrote:
In that case, the read-only data needs its own section. There are a few bits still available in the MCRR CSR, perhaps they can be used to encode fixed-length regions that immediately follows the code section which is the read-only section. For (a sketchy) example:
MCRR[2:0] can be used to encode a number from zero to seven inclusive, then the read-only region is the region that immediately follows the code section, its size is 2^(8 + MCRR[2:0]). The last byte of the code section needs some careful treatment. That gives a read-only section of size from 256 bytes to 32K bytes, which could be sufficient for really simple systems.
Siqi, I agree that if we want to protect read-only regions that are purefly for data consumption we'll need to handle that in a specific way. Thanks for the suggestion as a way to make that happen.
I personally wish machine mode had paging as that'd make things more flexible w.r.t. layering attributes over the physical address space. It's obviously not there now, but it would make such approaches easier.
|
|
|
Allen Baum
ePMP makes several changes. One is to separate M for S/U. Another is to then add shared regions (with specific permissions) on top of that. Another is to temporarily allow locked behavior without actually locking. And a fourth is to change the default no-match behavior from default Mmode allow to default disallow. (S/U is always disallowed.) If your intent is to have a background rule that allows S/U everywhere except where there is no overriding rule Mmode,, then you can have a background "allow everything" rule - which costs nothing because it can be a fixed, readonly value.
So, clearly I'm not understanding the types of configurations you're trying to set up. Could you give an example, and we can see what ePMP might be missing ?
On Wed, Oct 27, 2021 at 12:16 PM Aaron Durbin < adurbin@...> wrote:
If you want security, adding paging to Mmode is not the approach you want to take. That's a backwards step. You don't want mapping, you want protection, and that's what this proposal, and PMPs provide.
My parting comment was on layering attributes over the physical address space protections -- e.g. read-only data. Nothing more. The real difference is that this proposal defines the Mmode regions that should be denied to S/U, instead of regions that are allowed to S/U modes.
I'm not sure there is much here that the ePMP proposal doesn't already cover, though. That is, implementing 2 ePMP registers will give you the same protections as 2 *pairs* of base/mask registers. The ePMP proposal is not that complicated, especially if you're trying to achieve the limited functionality defined here, because many fields and control bits can be hardwired.
I'd be interested to hear why you think this is so much simpler than ePMP. The IO control is a separate issue, and I don't know if the IOPMP proposal is simple enough for you.
It is my understanding that ePMP introduces the changes where mseccfg.MML changes the behavior of .L field in the PMP entries to mean L=1 machine mode and L=0 S/U for physical address space protection. While it does allow making a distinction between M and S/U regions, it doesn't change the default matching rules. As noted up thread:
"In effect, PMP can grant permissions to S and U modes, which by default have none, and can revoke permissions from M-mode, which by default has full permissions." "If no PMP entry matches an M-mode access, the access succeeds. If no PMP entry matches an S-mode or U-mode access, but at least one PMP entry is implemented, the access fails."
Therefore, one has to carve out S/U access for the entirety of the physical address space. Perhaps I missed the rules for matching being changed in the ePMP proposal?
On Wed, Oct 27, 2021 at 8:56 AM Aaron Durbin < adurbin@...> wrote:
In that case, the read-only data needs its own section. There are a few bits still available in the MCRR CSR, perhaps they can be used to encode fixed-length regions that immediately follows the code section which is the read-only section. For (a sketchy) example:
MCRR[2:0] can be used to encode a number from zero to seven inclusive, then the read-only region is the region that immediately follows the code section, its size is 2^(8 + MCRR[2:0]). The last byte of the code section needs some careful treatment. That gives a read-only section of size from 256 bytes to 32K bytes, which could be sufficient for really simple systems.
Siqi, I agree that if we want to protect read-only regions that are purefly for data consumption we'll need to handle that in a specific way. Thanks for the suggestion as a way to make that happen.
I personally wish machine mode had paging as that'd make things more flexible w.r.t. layering attributes over the physical address space. It's obviously not there now, but it would make such approaches easier.
|
|
|
