That might mean that the sPMP being considered might need a probe of some sort.

      Bill

On 10/30/20 3:39 PM, Jonathan Behrens wrote:

EXTERNAL MAIL

In the worst case, a software page table walk isn't that expensive.

On Fri, Oct 30, 2020 at 6:26 PM Andrew Waterman via lists.riscv.org <andrew=sifive.com@...> wrote:

On Fri, Oct 30, 2020 at 2:46 PM Bill Huffman <huffman@...> wrote:

On 10/30/20 2:32 PM, Andrew Waterman wrote:

EXTERNAL MAIL

On Fri, Oct 30, 2020 at 8:19 AM Xinhaoqu (Freddie) <xinhaoqu@...> wrote:

Hi Andrew,

 

I’m not sure the sstatus.SUM bit is providing the equivalent of LDTR/STTR. The pair of load/store instructions lower their privilege level so that if they end up access privileged locations, they will fault. On the other hand, when status.SUM==1, even if the page is marked as “User”, supervisor code can still access it.

 

From section 3.1.6.3 in the Privileged ISA spec:

 

The SUM (permit Supervisor User Memory access) bit modifies the privilege with which S-mode

loads and stores access virtual memory. When SUM=0, S-mode memory accesses to pages that are

accessible by U-mode (U=1 in Figure 4.17) will fault. When SUM=1, these accesses are permitted.

SUM has no effect when page-based virtual memory is not in effect. Note that, while SUM is

ordinarily ignored when not executing in S-mode, it is in effect when MPRV=1 and MPP=S. SUM

is hardwired to 0 if S-mode is not supported.

 

There is nothing mentioning what would happen if load/store instructions in S-mode attempt locations that require privilege. That means to me they are permitted when sstatus.SUM==1. This behaviour is fine in itself, but doesn’t match what the LDTR/STTR instructions do. I think sstatus.SUM’s equivalent is PSTATE.PAN, not LDTR/STTR. In other words, LDTR/STTR has no equivalent in RISC-V, AFAIK.

Right.  SUM can be used to solve the same problem as LDTR/STTR, but it is not equivalent.  To avoid the concern you describe, the Linux kernel first performs a bounds check to guarantee the address is in the user process' VA range.  Then, it engages SUM and performs the unprivileged access.

That's, of course, a very Linux centric answer.  With more general address maps - or a "bare MMU" - the problem is harder to solve.  Do you have an expectation for that case?

It's not especially Linux-centric; it's more conventional-OS-with-paging-centric.

mstatus.MPRV handles the situation adequately for PMP-based protection in M/U systems.

S-mode with general address maps is not adequately addressed here, but at least at the moment, that strikes me as a bit too hypothetical of a problem.  If we did need to solve it, an S-mode MPRV feature would also suffice.

       Bill

 

Regards,

Freddie

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Friday, October 30, 2020 9:50 AM
To: Andrea Mondelli <andrea.mondelli@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Access unprivileged regions from OS

 

 

 

On Fri, Oct 30, 2020 at 2:45 AM Andrea Mondelli via lists.riscv.org <andrea.mondelli=huawei.com@...> wrote:

Hi all,

quoting the arm manual, "sometimes the OS does need to access unprivileged regions, for example, to write to a buffer owned by an application. To support this, the instruction set provides the LDTR and STTR instructions."
According to the Volume II: RISC-V Privileged Architectures Chapter 7, In RISCV we don't have any similar privileged instruction to do it.

There is an alternative way to have the same behavior? I was thinking other examples like checking user parameters when syscall are called.

 

Yeah.  Set the sstatus.SUM bit, then use regular load and store instructions to access user memory, then clear sstatus.SUM.

 

Any hints?

thanks in advance

On 10/30/20 2:32 PM, Andrew Waterman wrote:

EXTERNAL MAIL

On Fri, Oct 30, 2020 at 8:19 AM Xinhaoqu (Freddie) <xinhaoqu@...> wrote:

Hi Andrew,

 

I’m not sure the sstatus.SUM bit is providing the equivalent of LDTR/STTR. The pair of load/store instructions lower their privilege level so that if they end up access privileged locations, they will fault. On the other hand, when status.SUM==1, even if the page is marked as “User”, supervisor code can still access it.

 

From section 3.1.6.3 in the Privileged ISA spec:

 

The SUM (permit Supervisor User Memory access) bit modifies the privilege with which S-mode

loads and stores access virtual memory. When SUM=0, S-mode memory accesses to pages that are

accessible by U-mode (U=1 in Figure 4.17) will fault. When SUM=1, these accesses are permitted.

SUM has no effect when page-based virtual memory is not in effect. Note that, while SUM is

ordinarily ignored when not executing in S-mode, it is in effect when MPRV=1 and MPP=S. SUM

is hardwired to 0 if S-mode is not supported.

 

There is nothing mentioning what would happen if load/store instructions in S-mode attempt locations that require privilege. That means to me they are permitted when sstatus.SUM==1. This behaviour is fine in itself, but doesn’t match what the LDTR/STTR instructions do. I think sstatus.SUM’s equivalent is PSTATE.PAN, not LDTR/STTR. In other words, LDTR/STTR has no equivalent in RISC-V, AFAIK.

Right.  SUM can be used to solve the same problem as LDTR/STTR, but it is not equivalent.  To avoid the concern you describe, the Linux kernel first performs a bounds check to guarantee the address is in the user process' VA range.  Then, it engages SUM and performs the unprivileged access.

That's, of course, a very Linux centric answer.  With more general address maps - or a "bare MMU" - the problem is harder to solve.  Do you have an expectation for that case?

       Bill

 

Regards,

Freddie

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Friday, October 30, 2020 9:50 AM
To: Andrea Mondelli <andrea.mondelli@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Access unprivileged regions from OS

 

 

 

On Fri, Oct 30, 2020 at 2:45 AM Andrea Mondelli via lists.riscv.org <andrea.mondelli=huawei.com@...> wrote:

Hi all,

quoting the arm manual, "sometimes the OS does need to access unprivileged regions, for example, to write to a buffer owned by an application. To support this, the instruction set provides the LDTR and STTR instructions."
According to the Volume II: RISC-V Privileged Architectures Chapter 7, In RISCV we don't have any similar privileged instruction to do it.

There is an alternative way to have the same behavior? I was thinking other examples like checking user parameters when syscall are called.

 

Yeah.  Set the sstatus.SUM bit, then use regular load and store instructions to access user memory, then clear sstatus.SUM.

 

Any hints?

thanks in advance

There is an alternative way to have the same behavior? I was thinking other examples like checking user parameters when syscall are called.

 

Yeah.  Set the sstatus.SUM bit, then use regular load and store instructions to access user memory, then clear sstatus.SUM.

 

 

Thanks Andrew, I’d forgotten about SUM bit!

But.

It means the privilege with which S-mode loads and store access virtual memory cannot be used for specific addresses (i.e. check the function parameters of a syscall) avoiding the sstatus update overhead, right? 

 

According to the manual, “Operating systems can execute the majority of code with SUM clear; the few code segments that

should access user memory can temporarily set SUM.” the SUM must be temporary set and unset per syscall, then.

 

Changes to the sstatus fields SUM take effect immediately, without the need to execute

an SFENCE.VMA instruction, so we cannot really consider this set/unset an overhead, probably.

 

Any (historical or practical) reason to avoid solutions like ad-hoc privileged instructions for this purpose?

Hi Andrew,

 

I’m not sure the sstatus.SUM bit is providing the equivalent of LDTR/STTR. The pair of load/store instructions lower their privilege level so that if they end up access privileged locations, they will fault. On the other hand, when status.SUM==1, even if the page is marked as “User”, supervisor code can still access it.

 

From section 3.1.6.3 in the Privileged ISA spec:

 

The SUM (permit Supervisor User Memory access) bit modifies the privilege with which S-mode

loads and stores access virtual memory. When SUM=0, S-mode memory accesses to pages that are

accessible by U-mode (U=1 in Figure 4.17) will fault. When SUM=1, these accesses are permitted.

SUM has no effect when page-based virtual memory is not in effect. Note that, while SUM is

ordinarily ignored when not executing in S-mode, it is in effect when MPRV=1 and MPP=S. SUM

is hardwired to 0 if S-mode is not supported.

 

There is nothing mentioning what would happen if load/store instructions in S-mode attempt locations that require privilege. That means to me they are permitted when sstatus.SUM==1. This behaviour is fine in itself, but doesn’t match what the LDTR/STTR instructions do. I think sstatus.SUM’s equivalent is PSTATE.PAN, not LDTR/STTR. In other words, LDTR/STTR has no equivalent in RISC-V, AFAIK.

 

Regards,

Freddie

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Friday, October 30, 2020 9:50 AM
To: Andrea Mondelli <andrea.mondelli@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Access unprivileged regions from OS

 

 

 

On Fri, Oct 30, 2020 at 2:45 AM Andrea Mondelli via lists.riscv.org <andrea.mondelli=huawei.com@...> wrote:

Hi all,

quoting the arm manual, "sometimes the OS does need to access unprivileged regions, for example, to write to a buffer owned by an application. To support this, the instruction set provides the LDTR and STTR instructions."
According to the Volume II: RISC-V Privileged Architectures Chapter 7, In RISCV we don't have any similar privileged instruction to do it.

There is an alternative way to have the same behavior? I was thinking other examples like checking user parameters when syscall are called.

 

Yeah.  Set the sstatus.SUM bit, then use regular load and store instructions to access user memory, then clear sstatus.SUM.

 

Any hints?

thanks in advance

Hi all,

quoting the arm manual, "sometimes the OS does need to access unprivileged regions, for example, to write to a buffer owned by an application. To support this, the instruction set provides the LDTR and STTR instructions."
According to the Volume II: RISC-V Privileged Architectures Chapter 7, In RISCV we don't have any similar privileged instruction to do it.

There is an alternative way to have the same behavior? I was thinking other examples like checking user parameters when syscall are called.

Any hints?

thanks in advance