PMP shared permissions for S and U


Jeff Scott
 

Hello,

 

I am curious why the PMP treats S and U mode accesses identically?  Is anyone aware of a standard extension that allows for different permissions for S and U?

 

Thanks,

 

Jeff


Greg Favor
 

PMP was architected to be a mechanism to protect M-mode software and resources from non-M-mode software and devices.  This complements the MMU which serves to protect and isolate between S-mode and U-mode (and between U-mode processes).  They are intended to be orthogonal and composable architectural components.

If you are looking for something that combines those two functions into one mechanism, then take a look at the new SPMP TG that is in the process of being formed as we speak.  I'm not certain, but I think that might be what you are looking for.  (Start of group meetings, etc. will be announced on relevant RVI email lists - including the Security HC's list since I believe this TG is being sponsored by that HC.)

Greg

On Mon, Aug 22, 2022 at 9:44 AM Jeff Scott <jeff.scott@...> wrote:

Hello,

 

I am curious why the PMP treats S and U mode accesses identically?  Is anyone aware of a standard extension that allows for different permissions for S and U?

 

Thanks,

 

Jeff


Jeff Scott
 

Hi Greg,

 

In our world we don’t have MMU, just PMP.  The inability to supply separate permissions to S and U limits the usefulness of PMP in our environment.

 

I subscribed to SPMP now.  I’ll send my question to that email list as well.

 

Thanks,

 

Jeff

 

From: Greg Favor <gfavor@...>
Sent: Monday, August 22, 2022 11:53 AM
To: Jeff Scott <jeff.scott@...>
Cc: tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] PMP shared permissions for S and U

 

Caution: EXT Email

PMP was architected to be a mechanism to protect M-mode software and resources from non-M-mode software and devices.  This complements the MMU which serves to protect and isolate between S-mode and U-mode (and between U-mode processes).  They are intended to be orthogonal and composable architectural components.

 

If you are looking for something that combines those two functions into one mechanism, then take a look at the new SPMP TG that is in the process of being formed as we speak.  I'm not certain, but I think that might be what you are looking for.  (Start of group meetings, etc. will be announced on relevant RVI email lists - including the Security HC's list since I believe this TG is being sponsored by that HC.)

 

Greg

 

On Mon, Aug 22, 2022 at 9:44 AM Jeff Scott <jeff.scott@...> wrote:

Hello,

 

I am curious why the PMP treats S and U mode accesses identically?  Is anyone aware of a standard extension that allows for different permissions for S and U?

 

Thanks,

 

Jeff


Manuel Offenberg <manuel.a.offenberg@...>
 

Jeff;

FYI. SPMP TG is awaiting final approval from Technical Steering Commitee. 

Regards,
Manuel Offenberg
Seagate Research

From: tech-privileged@... <tech-privileged@...> on behalf of Jeff Scott <jeff.scott@...>
Sent: Monday, August 22, 2022 10:02 AM
To: Greg Favor <gfavor@...>
Cc: tech-privileged@... <tech-privileged@...>
Subject: Re: [RISC-V] [tech-privileged] PMP shared permissions for S and U
 

 

This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.


Hi Greg,

 

In our world we don’t have MMU, just PMP.  The inability to supply separate permissions to S and U limits the usefulness of PMP in our environment.

 

I subscribed to SPMP now.  I’ll send my question to that email list as well.

 

Thanks,

 

Jeff

 

From: Greg Favor <gfavor@...>
Sent: Monday, August 22, 2022 11:53 AM
To: Jeff Scott <jeff.scott@...>
Cc: tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] PMP shared permissions for S and U

 

Caution: EXT Email

PMP was architected to be a mechanism to protect M-mode software and resources from non-M-mode software and devices.  This complements the MMU which serves to protect and isolate between S-mode and U-mode (and between U-mode processes).  They are intended to be orthogonal and composable architectural components.

 

If you are looking for something that combines those two functions into one mechanism, then take a look at the new SPMP TG that is in the process of being formed as we speak.  I'm not certain, but I think that might be what you are looking for.  (Start of group meetings, etc. will be announced on relevant RVI email lists - including the Security HC's list since I believe this TG is being sponsored by that HC.)

 

Greg

 

On Mon, Aug 22, 2022 at 9:44 AM Jeff Scott <jeff.scott@...> wrote:

Hello,

 

I am curious why the PMP treats S and U mode accesses identically?  Is anyone aware of a standard extension that allows for different permissions for S and U?

 

Thanks,

 

Jeff


Seagate Internal


Greg Favor
 

Note: I'm not sure if the TG's email list is up yet.  If not, check with the Security HC.


On Mon, Aug 22, 2022 at 10:02 AM Jeff Scott <jeff.scott@...> wrote:

Hi Greg,

 

In our world we don’t have MMU, just PMP.  The inability to supply separate permissions to S and U limits the usefulness of PMP in our environment.

 

I subscribed to SPMP now.  I’ll send my question to that email list as well.

 

Thanks,

 

Jeff

 

From: Greg Favor <gfavor@...>
Sent: Monday, August 22, 2022 11:53 AM
To: Jeff Scott <jeff.scott@...>
Cc: tech-privileged@...
Subject: [EXT] Re: [RISC-V] [tech-privileged] PMP shared permissions for S and U

 

Caution: EXT Email

PMP was architected to be a mechanism to protect M-mode software and resources from non-M-mode software and devices.  This complements the MMU which serves to protect and isolate between S-mode and U-mode (and between U-mode processes).  They are intended to be orthogonal and composable architectural components.

 

If you are looking for something that combines those two functions into one mechanism, then take a look at the new SPMP TG that is in the process of being formed as we speak.  I'm not certain, but I think that might be what you are looking for.  (Start of group meetings, etc. will be announced on relevant RVI email lists - including the Security HC's list since I believe this TG is being sponsored by that HC.)

 

Greg

 

On Mon, Aug 22, 2022 at 9:44 AM Jeff Scott <jeff.scott@...> wrote:

Hello,

 

I am curious why the PMP treats S and U mode accesses identically?  Is anyone aware of a standard extension that allows for different permissions for S and U?

 

Thanks,

 

Jeff


Anthony Coulter
 

Out of curiosity, what's the point of supporting S-mode if not to use paged virtual memory? My understanding of things was that S-mode provides virtual memory, a secondary level of interrupt/exception handling beneath M-mode (which can already handle interrupts and exceptions by itself), and nothing else. I also understood that S-mode had restricted access to the machine's hardware mainly to support virtualization---the idea is that it uses an interface that's designed to be easily intercepted (per the Popek-Goldberg rules on virtualization). I also assume (which may be wrong) that MMU-less systems are MMU-less because they can't afford the transistors and power, so I would not expect them to run hypervisors.

So if the problem is "PMP doesn't distinguish between S-mode and U-mode" my reflexive solution would be "Run your supervisor in M-mode, which has the added benefit of giving it direct access to the PMP registers."

Apparently there is enough demand for supervisor-mode PMPs that there's an SMPU task group and an Ssmpu spec in the works at https://github.com/riscv/riscv-tee/blob/main/Ssmpu/Ssmpu.pdf . But all the spec provides for motivation is that "it is desirable to enable S-mode OS to limit the physical addresseses accessible by U-mode software." Figure 1 in that document says that the M-mode monitor sits below the S-mode "MPU virtualization," but... why? Is the purpose to allow hypervisors to manage MPU entries? Is there more than that? And if so, why are people running hypervisors on systems that can't afford paged memory? I'm sorry if this is derailing the purpose of this discussion thread, but I'm genuinely curious.

Regards,
Anthony


Allen Baum
 

Not all OSes require or desire VM address mapping, especially in the embedded space (or so I've been led to believe) - yet they still need some level of privilege protection layering.
That's where this comes SPMP (or SMPU) comes in. M-mode above the Smode is for security monitors, boot firmware, etc. - and to protect the Smode OS, so that doesn't go away.


On Tue, Aug 23, 2022 at 7:06 AM Anthony Coulter <riscv@...> wrote:
Out of curiosity, what's the point of supporting S-mode if not to use paged virtual memory? My understanding of things was that S-mode provides virtual memory, a secondary level of interrupt/exception handling beneath M-mode (which can already handle interrupts and exceptions by itself), and nothing else. I also understood that S-mode had restricted access to the machine's hardware mainly to support virtualization---the idea is that it uses an interface that's designed to be easily intercepted (per the Popek-Goldberg rules on virtualization). I also assume (which may be wrong) that MMU-less systems are MMU-less because they can't afford the transistors and power, so I would not expect them to run hypervisors.

So if the problem is "PMP doesn't distinguish between S-mode and U-mode" my reflexive solution would be "Run your supervisor in M-mode, which has the added benefit of giving it direct access to the PMP registers."

Apparently there is enough demand for supervisor-mode PMPs that there's an SMPU task group and an Ssmpu spec in the works at https://github.com/riscv/riscv-tee/blob/main/Ssmpu/Ssmpu.pdf . But all the spec provides for motivation is that "it is desirable to enable S-mode OS to limit the physical addresseses accessible by U-mode software." Figure 1 in that document says that the M-mode monitor sits below the S-mode "MPU virtualization," but... why? Is the purpose to allow hypervisors to manage MPU entries? Is there more than that? And if so, why are people running hypervisors on systems that can't afford paged memory? I'm sorry if this is derailing the purpose of this discussion thread, but I'm genuinely curious.

Regards,
Anthony