Date   

Re: comments on PMP enhancements

Nick Kossifidis
 

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


Re: comments on PMP enhancements

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


On Mon, Feb 17, 2020 at 10:27 PM Nick Kossifidis via Lists.Riscv.Org <mick=ics.forth.gr@...> wrote:
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




Re: comments on PMP enhancements

Allen Baum
 

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. 
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.

Jonathan

On Mon, Feb 17, 2020 at 10:27 PM Nick Kossifidis via Lists.Riscv.Org <mick=ics.forth.gr@...> wrote:
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




Re: comments on PMP enhancements

John Hauser
 

Hi Allen,

Since it looks like you're responding to me, I'll try to answer.

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.
There are now three proposals that I know of. The original and most
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 we
continue to disallow them,
Though I neglected to say so in my document, I meant for these
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 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)
This sounds like Mr, Kurd's proposal, not mine.

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.
I totally agree. Haven't looked at it yet, though.

Regards,

- John Hauser


Re: comments on PMP enhancements

Nick Kossifidis
 

Hello Jonathan,

On 2/18/20 6:08 AM, Jonathan Behrens 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.
Page tables aren't vastly easier to modify, we are talking about doing
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 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.
Not having any code on M-mode that touches PMP CSRs doesn't make much
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,
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.
Let me point out that the current spec only allows locked rules for
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


Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Mr Tariq Kurd <tariq.kurd@...>
 

Hi Nick, John,

Here's my proposal for adding two fields to the proposed MSECCFG CSR: DPL and DMC.

This proposal assumes that the programming model for the permissions is sufficient without adding another bit per PMP entry. If this is not the case then we should look further at adding another bit (M-bit in my proposal, or John's proposal).

If we think that the programming model is sufficient then hopefully adding these two bits can solve my problem in a simple way

Reading through this thread there is still an open question about programming SPMP permissions, for example, which we should resolve.

Tariq

-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of Nick Kossifidis
Sent: 18 February 2020 03:27
To: John Hauser <jh.riscv@...>
Cc: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

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


Re: enhanced PMP with four security levels

John Hauser
 

Hello all,

I've created a more convenient PDF document of my proposal to give our
enhanced PMP four security levels, available here:
http://www.jhauser.us/RISCV/Hauser_enhancedPMP-0.2.pdf

The purpose is to provide additional options for better protection than
MML = 0, for those times when it is not yet possible to set MML = 1.
More rationale is in the document.

Regards,

- John Hauser


Re: enhanced PMP with four security levels

Allen Baum
 


Here is my visual cheat sheet showing the 3 proposals

On Tue, Feb 18, 2020 at 10:25 AM John Hauser <jh.riscv@...> wrote:
Hello all,

I've created a more convenient PDF document of my proposal to give our
enhanced PMP four security levels, available here:
http://www.jhauser.us/RISCV/Hauser_enhancedPMP-0.2.pdf

The purpose is to provide additional options for better protection than
MML = 0, for those times when it is not yet possible to set MML = 1.
More rationale is in the document.

Regards,

    - John Hauser




Re: enhanced PMP with four security levels

John Hauser
 

Allen Baum wrote:
Here is my visual cheat sheet showing the 3 proposals
I've attached my own version, somewhat simplified. (I edited Allen's
file with LibreOffice on Linux. Hope it comes through clear for
everyone.)

Since the MML and MSL variables serve the same purpose, I've rearranged
the tables to keep those dimensions aligned. Also, I feel that the
question of whether a "security exception" or an ordinary access fault
is taken is an entirely separate debate, so I removed that distinction
from the tables. I've made some other simplifications and realignments
to aid comparison, as you'll see.

Regards,

- John Hauser


Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

Mr Tariq Kurd <tariq.kurd@...>
 

Thanks Allen and John,

I found John's version easier to read and I have added an extra sheet "permissions" to it showing the effect of the 4 different schemes. I give an idea of how to program the different modes, but I'm mainly showing which combinations of

M-mode permissions
S/U-mode permissions
Locked / unlocked

....are possible.

I'm planning to use this to help an internal discussion on the options in the next few days.

Tariq

-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of John Hauser
Sent: 19 February 2020 06:23
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

Allen Baum wrote:
Here is my visual cheat sheet showing the 3 proposals
I've attached my own version, somewhat simplified. (I edited Allen's file with LibreOffice on Linux. Hope it comes through clear for
everyone.)

Since the MML and MSL variables serve the same purpose, I've rearranged the tables to keep those dimensions aligned. Also, I feel that the question of whether a "security exception" or an ordinary access fault is taken is an entirely separate debate, so I removed that distinction from the tables. I've made some other simplifications and realignments to aid comparison, as you'll see.

Regards,

- John Hauser


Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

Allen Baum
 

I'm going to suggest removing the DMC bit and replacing it with "any region locked".
This is a lot less expensive than a configuration bit, and I'd argue it gives you the functionality you need.

On Wed, Feb 19, 2020 at 9:12 AM Mr Tariq Kurd <tariq.kurd@...> wrote:
Thanks Allen and John,

I found John's version easier to read and I have added an extra sheet "permissions" to it showing the effect of the 4 different schemes. I give an idea of how to program the different modes, but I'm mainly showing which combinations of

M-mode permissions
S/U-mode permissions
Locked / unlocked

....are possible.

I'm planning to use this to help an internal discussion on the options in the next few days.

Tariq


-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of John Hauser
Sent: 19 February 2020 06:23
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] enhanced PMP with four security levels

Allen Baum wrote:
> Here is my visual cheat sheet showing the 3 proposals

I've attached my own version, somewhat simplified.  (I edited Allen's file with LibreOffice on Linux.  Hope it comes through clear for
everyone.)

Since the MML and MSL variables serve the same purpose, I've rearranged the tables to keep those dimensions aligned.  Also, I feel that the question of whether a "security exception" or an ordinary access fault is taken is an entirely separate debate, so I removed that distinction from the tables.  I've made some other simplifications and realignments to aid comparison, as you'll see.

Regards,

    - John Hauser







Re: comments on PMP enhancements

John Hauser
 

Hello all,

Concerning the proposal from Tariq Kurd (Huawei) with separate M and L
bits in PMP configuration bytes, in my view there are two details
that should disqualify it from consideration, at least as currently
designed:

First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode. In
the task group's working proposal and in my proposal for four security
levels, when higher security is enabled (MML = 1 or MSL > 0), these
locked PMP entries retain their enforcement for M mode but deny all
access to S/U mode. The M & L proposal does the opposite: It denies
all access to M mode and gives access to S/U mode! If an earlier
stage of boot software is unaware of the PMP extension, it might easily
create such locked entries (L = 1, M = 0), after which M mode will be
helpless to deny S/U access, or grant itself access when MML = 1. That
looks obviously wrong to me.

Second, the M & L proposal doesn't currently offer an option to totally
lock down the executable regions for M mode, a feature touted for the
task group's working proposal and kept in my proposal with MSL = 3. I
see no reason why this feature should be abandoned.

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.

The one feature clearly offered by the M & L proposal and not by
the other two is the ability to lock PMP entries that allow S/U-mode
access. But on this point, I have to agree with Nick Kossifidis: I
don't see a need for this ability.

Regards,

- John Hauser


Re: comments on PMP enhancements

Jonathan Behrens <behrensj@...>
 



On Wed, Feb 19, 2020 at 3:46 PM John Hauser via Lists.Riscv.Org <jh.riscv=jhauser.us@...> wrote:
Hello all,

Concerning the proposal from Tariq Kurd (Huawei) with separate M and L
bits in PMP configuration bytes, in my view there are two details
that should disqualify it from consideration, at least as currently
designed:

First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode.  In
the task group's working proposal and in my proposal for four security
levels, when higher security is enabled (MML = 1 or MSL > 0), these
locked PMP entries retain their enforcement for M mode but deny all
access to S/U mode.  The M & L proposal does the opposite:  It denies
all access to M mode and gives access to S/U mode!  If an earlier
stage of boot software is unaware of the PMP extension, it might easily
create such locked entries (L = 1, M = 0), after which M mode will be
helpless to deny S/U access, or grant itself access when MML = 1.  That
looks obviously wrong to me.

Second, the M & L proposal doesn't currently offer an option to totally
lock down the executable regions for M mode, a feature touted for the
task group's working proposal and kept in my proposal with MSL = 3.  I
see no reason why this feature should be abandoned.

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.

The one feature clearly offered by the M & L proposal and not by
the other two is the ability to lock PMP entries that allow S/U-mode
access.  But on this point, I have to agree with Nick Kossifidis:  I
don't see a need for this ability.

Remind me, did all the other proposals have a way to prevent the S/U-mode entries from being reconfigured to M-mode ones later? Locking M-mode entries doesn’t do a ton if more can be added later

Regards,

    - John Hauser




Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Allen Baum
 

You need to be careful with terminology. I am assuming that 
     "denying access to Mmode" means
    "denying the ability of M-mode to change an entry" ,  and not
    "denying access to the region defined by an entry".

But: if an entry is created (necessarily by M-mode) that is locked and such that M-mode can no longer touch that region but S/U mode can - that is either intentional or that M-mode code is buggy, in my opinion. And, even if that happens, M-mode code code always define an unlocked region of higher priority (unless it has allocated all the higher priority regions). Again, intentional or buggy M-mode code. We can't defend against stupid buggy code.

I also don't see why M&L (I assume you mean the current enhanced proposal) can't lock down a region which is executable, but I'm unclear what exactly you mean by this.
A region which is intended to be executable (by Mmode only) can be made as L-RX, so that code can no longer be altered, and when MM is set to 1 only Mmode code can execute it.
That's not much different than the separate M+L. I thought the reason for separate M+L was to give the ability to have unlocked unwritable regions that were inaccessible to S/U mode (so the M-mode region could be expanded without requiring using new entries).
 IF you didn't care about the unwritability, you can do this with the current enhanced proposal.
 There are a lot of hidden assumptions about the use model here, e.g. is it permitted to leave M-mode before the final (locked) M-mode configuration has been set up?
If not (and I'd like to know why that isn't a reasonable assumption) then separate M+L seems a bit less important.

Could you give me a more complete example where the current enhanced proposal doesn't do what you want?


On Wed, Feb 19, 2020 at 1:15 PM Jonathan Behrens <behrensj@...> wrote:


On Wed, Feb 19, 2020 at 3:46 PM John Hauser via Lists.Riscv.Org <jh.riscv=jhauser.us@...> wrote:
Hello all,

Concerning the proposal from Tariq Kurd (Huawei) with separate M and L
bits in PMP configuration bytes, in my view there are two details
that should disqualify it from consideration, at least as currently
designed:

First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode.  In
the task group's working proposal and in my proposal for four security
levels, when higher security is enabled (MML = 1 or MSL > 0), these
locked PMP entries retain their enforcement for M mode but deny all
access to S/U mode.  The M & L proposal does the opposite:  It denies
all access to M mode and gives access to S/U mode!  If an earlier
stage of boot software is unaware of the PMP extension, it might easily
create such locked entries (L = 1, M = 0), after which M mode will be
helpless to deny S/U access, or grant itself access when MML = 1.  That
looks obviously wrong to me.

Second, the M & L proposal doesn't currently offer an option to totally
lock down the executable regions for M mode, a feature touted for the
task group's working proposal and kept in my proposal with MSL = 3.  I
see no reason why this feature should be abandoned.

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.

The one feature clearly offered by the M & L proposal and not by
the other two is the ability to lock PMP entries that allow S/U-mode
access.  But on this point, I have to agree with Nick Kossifidis:  I
don't see a need for this ability.

Remind me, did all the other proposals have a way to prevent the S/U-mode entries from being reconfigured to M-mode ones later? Locking M-mode entries doesn’t do a ton if more can be added later

Regards,

    - John Hauser




Re: comments on PMP enhancements

John Hauser
 

Jonathan Behrens wrote:
Remind me, did all the other proposals have a way to prevent the S/U-mode
entries from being reconfigured to M-mode ones later? Locking M-mode
entries doesn’t do a ton if more can be added later
Because the PMP table is explicitly searched in order for a match,
locked entries must always be at the head of the table to be truly
effective. When software wants to add a locked entry, there may be
N locked entries already in the table in positions 0 through N - 1.
If entry N is in use (not locked), it must be moved to a later position
(possibly by shifting down the entire table by one position), after
which the new locked entry can be added in position N. Usually,
software can manage the table better and avoid a lot of shifting.

Locked entries at the head of the PMP table certainly cannot be
subverted, even if entries can still be added or modified below them.

To totally lock down executable regions for M mode, at the highest
security level both the task group's working proposal and my proposal
prevent the creation of new PMP entries that grant execute permission
to M mode.

A properly configured locked PMP entry can constrain or entirely
prevent M-mode access to any memory region. In the absence of such an
entry, M mode is assumed to have authority to read/write anything it
wants, within the underlying constraints of physical memory attributes
(PMAs). Given that policy, none of the enhanced PMP proposals prevent
M mode from creating new PMP entries for itself, except as I've already
explained.

- John Hauser


Re: comments on PMP enhancements

John Hauser
 

I wrote:
First, as we all know, the existing PMP standard allows PMP entries to
be locked, with the clear intention of denying access to M mode.
Allen Baum:
You need to be careful with terminology. I am assuming that
"denying access to Mmode" means
"denying the ability of M-mode to change an entry" , and not
"denying access to the region defined by an entry".
Sorry, I meant that, under the existing standard, locked PMP entries
are intended to deny some or all accesses from M mode to a memory
region. The RISC-V standard says, "In addition to locking the PMP
entry, the L bit indicates whether the R/W/X permissions are enforced
on M-mode accesses." The only reason the entry is locked is so that
M mode can't then undo this restriction imposed on it.

But: if an entry is created (necessarily by M-mode) that is locked and such
that M-mode can no longer touch that region but S/U mode can - that is
either intentional or that M-mode code is buggy, in my opinion.
Such an entry is impossible under the existing standard. There's no
way to encode it.

And, even
if that happens, M-mode code code always define an unlocked region of
higher priority (unless it has allocated all the higher priority regions).
As I said to Jonathan Behrens, locked regions always have to be at the
head of the table to be effective. Ordinarily, there won't be any
unlocked regions of higher priority.

It feels like you've misunderstood the role of locked PMP entries under
the existing standard, and that's why you didn't understand my point.
Or you missed the significance I intended with my words "the existing
PMP standard allows ...."

Regards,

- John Hauser


Re: comments on PMP enhancements

John Hauser
 

I wrote:
Second, the M & L proposal doesn't currently offer an option to totally
lock down the executable regions for M mode, a feature touted for the
task group's working proposal and kept in my proposal with MSL = 3. I
see no reason why this feature should be abandoned.
Allen Baum:
I also don't see why M&L (I assume you mean the current enhanced proposal)
can't lock down a region which is executable, but I'm unclear what exactly
you mean by this. [...]
By the "M & L proposal" I meant Tariq Kurd's proposal, the one I was
speaking of. (On your own cheat sheet from yesterday, the tab for this
proposal is labeled "sep_M&L". But I now see that the word "separate"
is a crucial part of your labelling, whereas I thought it could just be
implied.)

Anyway, getting back to the point, in the task group's document, part
3(b) of the proposal says that when MML = 1,

Adding a new PMP rule with pmpcfg.L and pmpcfg.X bits is not
possible and such pmpcfg writes are ignored, leaving pmpcfg
unchanged.

This goes beyond the ability to create a locked PMP entry; it
independently _prevents_ the ability to create new entries of the type
specified. The rationale for this is in the document's "Rationale"
section, where it is briefly explained that this limits the attack
surface as much as possible.

My own four-security-level proposal duplicates this rule in section 2.4:

In addition, level 3 prevents the configuration of new locked PMP
entries that give execute permission to M mode (PL = 2 or 3, with
bit X = 1). An attempt to configure such an entry is ignored.

Replicating this condition is in fact the _only reason_ my proposal
needs the topmost security setting, MSL = 3.

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.

- John Hauser


How can M mode emulate instructions if it is locked down?

Andy Glew Si5
 

Creating a new thread, for a new topic, although I'm excerpting some old
email as inspiration.

Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is
to emulate instructions.

For example, a hardware implementation may not implement misaligned memory
accesses. But these can trap to M mode, which can emulate.

Q: doesn't MML, M-mode lockdown, preventing M-mode from reading or
writing, interfere with such emulation? At least in the cases where the
M-mode code needs to actually perform memory accesses on behalf of the
code that it is emulating.

My apologies if this is already been discussed. I mentioned this to Andrew
a week or so ago, meant to post to this list, but I want to read all the
history before I embarrass myself. That hasn't happened, so I just want to
send this email and risk embarrassing myself and wasting your time if you
have already discussed this.

I can't resist a meta-observation: M-mode is going the way of Intel SMM.
There are too many different uses, which should be indifferent privileged
domains, that are being crammed into the single M-mode privileged level.

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On
Behalf Of John Hauser
Sent: Wednesday, February 19, 2020 14:29
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] comments on PMP enhancements

... under the existing standard, locked PMP entries are intended to deny
some or all accesses from M mode to a memory region. The RISC-V standard
says, "In addition to locking the PMP entry, the L bit indicates whether
the R/W/X permissions are enforced on M-mode accesses." The only reason
the entry is locked is so that M mode can't then undo this restriction
imposed on it.


Re: How can M mode emulate instructions if it is locked down?

Jonathan Behrens <behrensj@...>
 

Hi Andy,

M-mode can use mstatus.mprv to access S/U-mode memory regions, provided that S/U-mode has read access to them. If any non-readable regions are configured then trap-and-emulate won't be possible for them. However, it has been pointed out that this wouldn't be a huge issue because non-readable regions are also non-writable. This means that once the relevant PMP entry is installed, the contents of that memory is fixed and so M-mode can be sure that no instructions requiring emulation are placed in that region.

Regarding your point about M-mode becoming similar to Intel SMM, I share your concern. I also worry that it might also end up resembling SMM in the sense that the actual owner of the CPU ends up having very limited visibility or control over the most privileged code that is being run.

Jonathan


On Wed, Feb 19, 2020 at 8:01 PM Andy Glew Si5 via Lists.Riscv.Org <andy.glew=sifive.com@...> wrote:
Creating a new thread, for a new topic, although I'm excerpting some old
email as inspiration.

Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is
to emulate instructions.

For example, a hardware implementation may not implement misaligned memory
accesses. But these can trap to M mode, which can emulate.

Q: doesn't MML, M-mode lockdown, preventing M-mode from reading or
writing, interfere with such emulation? At least in the cases where the
M-mode code needs to actually perform memory accesses on behalf of the
code that it is emulating.

My apologies if this is already been discussed. I mentioned this to Andrew
a week or so ago, meant to post to this list, but I want to read all the
history before I embarrass myself. That hasn't happened, so I just want to
send this email and risk embarrassing myself and wasting your time if you
have already discussed this.

I can't resist a meta-observation: M-mode is going the way of Intel SMM.
There are too many different uses, which should be indifferent privileged
domains, that are being crammed into the single M-mode privileged level.

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On
Behalf Of John Hauser
Sent: Wednesday, February 19, 2020 14:29
To: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] comments on PMP enhancements

... under the existing standard, locked PMP entries are intended to deny
some or all accesses from M mode to a memory region.  The RISC-V standard
says, "In addition to locking the PMP entry, the L bit indicates whether
the R/W/X permissions are enforced on M-mode accesses."  The only reason
the entry is locked is so that M mode can't then undo this restriction
imposed on it.




Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Joe Xie
 

Hi Tariq, all,

After a rethink, I actually think that the restriction imposed by lock is a good feature to security.

For example, in your use case that BR wants to lockdown its sub-regions one by one to prevent FI, one solution is to move most BR code to U mode and just leave a small piece of PMP management code in M mode, the M mode FW then can only enable U mode region when needed.

So I am really not sure we want to add more flexibility to loosen M mode protections if pushing SW to U mode can solve the problem and makes your M mode FW more secure. Do you agree?

I am ok with the DMC bit as it is clear and saves one region. Currently in our implementation we use background entry, but yes I agree 16 PMP entry is a problem..

-----Original Message-----
From: tech-privileged@... <tech-privileged@...> On Behalf Of Mr Tariq Kurd
Sent: Wednesday, February 19, 2020 1:13 AM
To: Nick Kossifidis <mick@...>; John Hauser <jh.riscv@...>
Cc: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

External email: Use caution opening links or attachments


Hi Nick, John,

Here's my proposal for adding two fields to the proposed MSECCFG CSR: DPL and DMC.

This proposal assumes that the programming model for the permissions is sufficient without adding another bit per PMP entry. If this is not the case then we should look further at adding another bit (M-bit in my proposal, or John's proposal).

If we think that the programming model is sufficient then hopefully adding these two bits can solve my problem in a simple way

Reading through this thread there is still an open question about programming SPMP permissions, for example, which we should resolve.

Tariq

-----Original Message-----
From: tech-tee@... [mailto:tech-tee@...] On Behalf Of Nick Kossifidis
Sent: 18 February 2020 03:27
To: John Hauser <jh.riscv@...>
Cc: tech-tee@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

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







-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

41 - 60 of 1210