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

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

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