Date
1 - 7 of 7
comments on PMP enhancements
John Hauser
Nick Kossifidis wrote:
locking of regions for the next boot stages, when that's appropriate.
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.
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.
For my part, I will try to be much more careful about my use of the
words "secure" and "security" going forward.
Regards,
- John Hauser
You don't need to do a ROP attack on BootROM to remove the rules, anyI'd like to point out that my own proposal does always allow for the
code that runs on M-mode can remove them in a few instructions. I don't
see how we can have a security control on M mode without also locking
the rules for preventing further modifications from the next boot
stages. [...]
locking of regions for the next boot stages, when that's appropriate.
When defining security controls there are guarantees we put in place.If unlocked M-mode PMP entries can't be called security controls, then
Let's say that we did everything correctly, both in hw and sw, up to the
point where we place the PMP rule there to prevent "other software"
running on M-mode from accessing some memory region. Can we guarantee
that this restriction will be enforced and that "other software" can't
simply bypass it ? I don't believe we can provide such a guarantee,
hence we can't claim this approach to be a security control. If the code
we are trying to restrict has direct control over the security control,
then it's not a security control, it's an ilusion of a security control.
To the contrary it may pose a security threat.
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.
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.
For my part, I will try to be much more careful about my use of the
words "secure" and "security" going forward.
Regards,
- John Hauser
Two quick comments:
- I am assuming that this is a proposal to replace the existing "enhanced" PMP proposal, rather than an "enhanced-enhanced" PMP proposal.
- do we ever need to allow Write_Only and Write&Execute regions? OR can we continue to disallow them, except for the specific shared RW/RO regions defined by the enhanced proposal
( which in this case is when MML=1, M=0 as opposed to the enhanced proposal of MML=1, L=0)
Separately, there is a proposal to have an S-PMP, which further filters addresses but allows Smode to configure them.
It would be useeful to consider whether they would be completely separate CSRs or they could overlay the existing ones ones somehow.
Even if they are totally separate, it would be useful to ensure the encodings were similar enough that the same HW (with simple external wiring changes) would work for both.
On Fri, Feb 14, 2020 at 12:57 PM John Hauser <jh.riscv@...> wrote:
Nick Kossifidis wrote:
> You don't need to do a ROP attack on BootROM to remove the rules, any
> code that runs on M-mode can remove them in a few instructions. I don't
> see how we can have a security control on M mode without also locking
> the rules for preventing further modifications from the next boot
> stages. [...]
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.
> When defining security controls there are guarantees we put in place.
> Let's say that we did everything correctly, both in hw and sw, up to the
> point where we place the PMP rule there to prevent "other software"
> running on M-mode from accessing some memory region. Can we guarantee
> that this restriction will be enforced and that "other software" can't
> simply bypass it ? I don't believe we can provide such a guarantee,
> hence we can't claim this approach to be a security control. If the code
> we are trying to restrict has direct control over the security control,
> then it's not a security control, it's an ilusion of a security control.
> To the contrary it may pose a security threat.
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.
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.
For my part, I will try to be much more careful about my use of the
words "secure" and "security" going forward.
Regards,
- John Hauser
mick@...
Hello John,
Στις 2020-02-14 22:56, John Hauser έγραψε:
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 ?
Regards,
Nick
Στις 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.
locking of regions for the next boot stages, when that's appropriate.
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 ?
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.
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.
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.
Regards,
Nick
Jonathan Behrens <behrensj@...>
Coming from an operating systems background, the concern about locking PMP entries being absolutely necessary for security comes across as overblown. I've never heard of a platform that provided locking functionality for page tables, yet no one says that all operating systems are insecure because of that. And page tables are vastly easier to modify: any store instruction in the entire text segment could be targeted to overwrite a PTE. By contrast, overwriting PMP entries requires dedicated PMP CSR instructions which appear in a handful of functions at most (if that!). Thinking about it, you could achieve basically the same effect as locking just by configuring the PMP so that all M-mode executable regions were read only and contained no PMP CSR instructions.
None of this is to say that we shouldn't supported locked PMP regions, just that it is important to be realistic about what benefit in practice they'd carry over the write XOR execute unlocked regions. Similarly, it is definitely worth trying to keep PMP as simple as possible while still providing the necessary functionality.
Jonathan
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
I read the proposed changes (some of them at least) as reducing the cost of security, not so much adding security or making it more secure.
toggle quoted message
Show quoted text
E.g. having a default rule costs a single bit rather using up two of the 16 PMP entries (even if those entries have fixed readonly limits) and being able to modify Mmode rules and then locking them means you can incrementally expand a locked Mmode region without using more entries each time.
There are other ways this could be implemented (not that I’m proposing them), e.g. allowing the upper limit of locked regions to be written iff new_limit>old_limit.
-Allen
On Feb 17, 2020, at 8:08 PM, Jonathan Behrens <behrensj@...> wrote:
Coming from an operating systems background, the concern about locking PMP entries being absolutely necessary for security comes across as overblown. I've never heard of a platform that provided locking functionality for page tables, yet no one says that all operating systems are insecure because of that. And page tables are vastly easier to modify: any store instruction in the entire text segment could be targeted to overwrite a PTE. By contrast, overwriting PMP entries requires dedicated PMP CSR instructions which appear in a handful of functions at most (if that!). Thinking about it, you could achieve basically the same effect as locking just by configuring the PMP so that all M-mode executable regions were read only and contained no PMP CSR instructions.None of this is to say that we shouldn't supported locked PMP regions, just that it is important to be realistic about what benefit in practice they'd carry over the write XOR execute unlocked regions. Similarly, it is definitely worth trying to keep PMP as simple as possible while still providing the necessary functionality.JonathanHello 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
John Hauser
Hi Allen,
Since it looks like you're responding to me, I'll try to answer.
visible is the task group's working proposal, which you already know.
The only version I've seen is here:
https://docs.google.com/document/d/1Mh_aiHYxemL0umN3GTTw8vsbmzHZ_nxZXgjgOUzbvc8/edit#heading=h.ab3kl2ch725u
As part of my feedback, I suggested a modified proposal with four
"security levels". To make this more accessible, I've now created a
simple PDF document, which can be found here:
http://www.jhauser.us/RISCV/Hauser_enhancedPMP-0.2.pdf
As the document explains, my top-most security level (what I'm now
calling "full security") is for all practical purposes the same as the
task group's proposal when MML = 1. The important difference is that
I offer two "proto-security" levels that provide better protection than
you get with MML = 0, which is the only alternative to "full security"
under the task group's working proposal. I would be pleased if you
could give my proposal a look and give me your thoughts.
Tariq Kurd has been developing a different modified proposal. I need
to review his latest version, but when I last looked, it appeared to me
to satisify the needs of his system in a slightly more complex way than
my proposal, without any advantage. Hence, I confess I haven't yet
seen the appeal. I'll try again.
combinations to continue to be reserved encodings. If anyone is
proposing write-only or write/execute permissions, I'm not yet aware of
it.
Regards,
- John Hauser
Since it looks like you're responding to me, I'll try to answer.
Two quick comments:There are now three proposals that I know of. The original and most
- I am assuming that this is a proposal to replace the existing "enhanced"
PMP proposal, rather than an "enhanced-enhanced" PMP proposal.
visible is the task group's working proposal, which you already know.
The only version I've seen is here:
https://docs.google.com/document/d/1Mh_aiHYxemL0umN3GTTw8vsbmzHZ_nxZXgjgOUzbvc8/edit#heading=h.ab3kl2ch725u
As part of my feedback, I suggested a modified proposal with four
"security levels". To make this more accessible, I've now created a
simple PDF document, which can be found here:
http://www.jhauser.us/RISCV/Hauser_enhancedPMP-0.2.pdf
As the document explains, my top-most security level (what I'm now
calling "full security") is for all practical purposes the same as the
task group's proposal when MML = 1. The important difference is that
I offer two "proto-security" levels that provide better protection than
you get with MML = 0, which is the only alternative to "full security"
under the task group's working proposal. I would be pleased if you
could give my proposal a look and give me your thoughts.
Tariq Kurd has been developing a different modified proposal. I need
to review his latest version, but when I last looked, it appeared to me
to satisify the needs of his system in a slightly more complex way than
my proposal, without any advantage. Hence, I confess I haven't yet
seen the appeal. I'll try again.
- do we ever need to allow Write_Only and Write&Execute regions? OR can weThough I neglected to say so in my document, I meant for these
continue to disallow them,
combinations to continue to be reserved encodings. If anyone is
proposing write-only or write/execute permissions, I'm not yet aware of
it.
except for the specific shared RW/RO regionsThis sounds like Mr, Kurd's proposal, not mine.
defined by the enhanced proposal
( which in this case is when MML=1, M=0 as opposed to the enhanced
proposal of MML=1, L=0)
Separately, there is a proposal to have an S-PMP, which further filtersI totally agree. Haven't looked at it yet, though.
addresses but allows Smode to configure them.
It would be useeful to consider whether they would be completely separate
CSRs or they could overlay the existing ones ones somehow.
Even if they are totally separate, it would be useful to ensure the
encodings were similar enough that the same HW (with simple external wiring
changes) would work for both.
Regards,
- John Hauser
mick@...
Hello Jonathan,
On 2/18/20 6:08 AM, Jonathan Behrens wrote:
page table walking, finding the pte you want to modify and then modify
the one used by the hardware and also the version used internaly by the
OS (e.g. for lazy binding). While doing that the OS may change the page
table e.g. to merge ptes in hugepages and I'm just getting started (in
one of our projects we had to keep two page tables in sync across
different systems for doing RDMA between applications, we did that at
the kernel level with all the privileges we wanted and it was still a
chalenge). In contrast modifying a PMP entry takes one instruction and
since it's per-hart no one else will access / monitor it while
performing an attack.
Also page tables are managed by the OS wich is one privilege level above
the application that page tables are used to restrict. Applications
can't modify the page table and I don't think you'll find any platform /
OS where this is possible. On RISC-V for example U mode is not allowed
to access satp. In this case we are talking about PMP rules used to
restrict M-mode. If M-mode is allowed to modify them then we are a few
instructions away from rendering this mechanism useless. We are not
talking about having all PMP rules being locked, just the rules used to
restrict M-mode since there is no one above M-mode to manage M-mode
restrictions.
Page tables were invented mainly for managing virtual memory mappings,
memory protections came later on and in many cases are not enough (we
can only set permissions per-page, there are many cases where we want to
set different permissions within a page, that's where things like memory
tagging come into play). Because of their functionality they can't be
locked, they are meant to be modified all the time and switched on every
context switch. We can't compare PMP which only handles memory
protection with page tables. Protecting page tables is an open issue and
there are many approaches used for ensuring their integrity, from
hypervisors to encrypted memory etc. Not having heard of OSes being
insecure because of attacks on page tables doesn't mean they are secure,
it's just hard to deal with this issue and if someone has the privilege
to modify page tables (that is running with OS privileges) there are
easier and far more effective attacks to perform.
sense. If M-mode doesn't configure PMP, who will ? No other privilege
mode has access to the PMP registers and there are many cases in which
we would want to modify PMP settings e.g. when switching between trusted
apps. Also not every attack works via ROP or modifying the control flow
to re-use some code from elsewere, there are attacks that inject code as
well, or executing code with higher privileges (that's the attack we are
trying to mitigate in our proposal by the way). Finaly even if we accept
that the threat model here is a control-flow based attack, it's not
about how many functions modify the rules, it's about how many functions
are calling them.
restricting M-mode, and for good reasons. We are not trying to change
that nor make the mechanism more complicated. What we are trying to do
is mitigate a specific attack, allow for better / cleaner isolation
between M-mode and S/U-mode, and do that in the least invasive way
possible. I think the group's proposal does the job and provides a good
base for other mechanisms to be defined in the future.
Regards,
Nick
On 2/18/20 6:08 AM, Jonathan Behrens wrote:
Coming from an operating systems background, the concern about lockingPage tables aren't vastly easier to modify, we are talking about doing
PMP entries being absolutely necessary for security comes across as
overblown. I've never heard of a platform that provided locking
functionality for page tables, yet no one says that all operating
systems are insecure because of that. And page tables are vastly easier
to modify: any store instruction in the entire text segment could be
targeted to overwrite a PTE.
page table walking, finding the pte you want to modify and then modify
the one used by the hardware and also the version used internaly by the
OS (e.g. for lazy binding). While doing that the OS may change the page
table e.g. to merge ptes in hugepages and I'm just getting started (in
one of our projects we had to keep two page tables in sync across
different systems for doing RDMA between applications, we did that at
the kernel level with all the privileges we wanted and it was still a
chalenge). In contrast modifying a PMP entry takes one instruction and
since it's per-hart no one else will access / monitor it while
performing an attack.
Also page tables are managed by the OS wich is one privilege level above
the application that page tables are used to restrict. Applications
can't modify the page table and I don't think you'll find any platform /
OS where this is possible. On RISC-V for example U mode is not allowed
to access satp. In this case we are talking about PMP rules used to
restrict M-mode. If M-mode is allowed to modify them then we are a few
instructions away from rendering this mechanism useless. We are not
talking about having all PMP rules being locked, just the rules used to
restrict M-mode since there is no one above M-mode to manage M-mode
restrictions.
Page tables were invented mainly for managing virtual memory mappings,
memory protections came later on and in many cases are not enough (we
can only set permissions per-page, there are many cases where we want to
set different permissions within a page, that's where things like memory
tagging come into play). Because of their functionality they can't be
locked, they are meant to be modified all the time and switched on every
context switch. We can't compare PMP which only handles memory
protection with page tables. Protecting page tables is an open issue and
there are many approaches used for ensuring their integrity, from
hypervisors to encrypted memory etc. Not having heard of OSes being
insecure because of attacks on page tables doesn't mean they are secure,
it's just hard to deal with this issue and if someone has the privilege
to modify page tables (that is running with OS privileges) there are
easier and far more effective attacks to perform.
By contrast, overwriting PMP entriesNot having any code on M-mode that touches PMP CSRs doesn't make much
requires dedicated PMP CSR instructions which appear in a handful of
functions at most (if that!). Thinking about it, you could achieve
basically the same effect as locking just by configuring the PMP so that
all M-mode executable regions were read only and contained no PMP CSR
instructions.
sense. If M-mode doesn't configure PMP, who will ? No other privilege
mode has access to the PMP registers and there are many cases in which
we would want to modify PMP settings e.g. when switching between trusted
apps. Also not every attack works via ROP or modifying the control flow
to re-use some code from elsewere, there are attacks that inject code as
well, or executing code with higher privileges (that's the attack we are
trying to mitigate in our proposal by the way). Finaly even if we accept
that the threat model here is a control-flow based attack, it's not
about how many functions modify the rules, it's about how many functions
are calling them.
None of this is to say that we /shouldn't/ supported locked PMP regions,Let me point out that the current spec only allows locked rules for
just that it is important to be realistic about what benefit in practice
they'd carry over the write XOR execute unlocked regions. Similarly, it
is definitely worth trying to keep PMP as simple as possible while still
providing the necessary functionality.
restricting M-mode, and for good reasons. We are not trying to change
that nor make the mechanism more complicated. What we are trying to do
is mitigate a specific attack, allow for better / cleaner isolation
between M-mode and S/U-mode, and do that in the least invasive way
possible. I think the group's proposal does the job and provides a good
base for other mechanisms to be defined in the future.
Regards,
Nick