Date   

PTE access type in Virtual Address Translation

Gracy Ge
 

From the Privileged spec, the 2nd step of virtual Address Translation process said, 
[2. Let pte be the value of the PTE at address a+va.vpn[i]×PTESIZE. (For Sv32, PTESIZE=4.)
If accessing pte violates a PMA or PMP check, raise an access exception corresponding to
the original access type.]
What is the required ACCESS type for PTE entries? I thought it should only have read access for non-leaf PTE and extra write access for leaf PTE(AD). Is this correct?
 


Re: Access unprivileged regions from OS

Allen Baum
 

The sPMP proposal has not been discussed in any detail as far as I know, so it is hard to pin down.
The advantage of sPMP is that it should be much lower cost and simpler compared to page-based virtual memory.
The downside is there is no ability to relocate addresses - it is less flexible.

My understanding of the intent (which could be wrong, to be clear) is that it primarily targets an embedded system that had 3 privilege levels (M,S,U) but didn't need virtual memory. In such a system,  the OS (S-mode) privilege level needs the ability to configure memory protection, but the existing PMP can only be configured by M-mode. sPMP was proposed to correct this.

The Trusted Execution Environment (TEE) is defining an enhanced PMP, but it still only differentiates between M-mode and non-M-Mode; specifically, it doesn't differentiate between S-mode and U-mode protections.
In any case, there have been no  sPMP discussions in any TG that I'm aware of yet. That could happen in the TEE TG, but certainly not before the enhanced PMP work is finished .

On Mon, Nov 2, 2020 at 2:18 AM Xinhao (Freddie) Qu via lists.riscv.org <xinhaoqu=huawei.com@...> wrote:

Is sPMP an alternative to page-based permissions? If so, what advantage does it provide over the latter?

 

Thanks,

Freddie

 

From: Andrew Waterman [mailto:andrew@...]
Sent: Friday, October 30, 2020 10:51 PM
To: Bill Huffman <huffman@...>
Cc: Jonathan Behrens <behrensj@...>; Xinhaoqu (Freddie) <xinhaoqu@...>; Andrea Mondelli <andrea.mondelli@...>; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Access unprivileged regions from OS

 

 

 

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

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

I'd tend to think that the user processes running under sPMP will have few enough data regions that software base-and-bounds checks on syscall arguments isn't prohibitively expensive.

 

      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


ARM's new capability-based security ISA (building on top of ARMv8)

Greg Favor
 

This is just a quick FYI.  (Sorry if this is a bit spam'y; there isn't a clear TG to target with this email.  And I don't expect that this is something that plays into any near-term RISC-V standardization efforts.)

ARM has been working on a capability-based architecture for a while, and has just now made public the arch spec (and related specs).  This work is based on the Cheri project at Cambridge.  If you're curious about it, this link provides a high-level summary and contain a link that will get you to the arch documents:  ARM Morello Program

Greg


Re: Access unprivileged regions from OS

Xinhao (Freddie) Qu
 

Is sPMP an alternative to page-based permissions? If so, what advantage does it provide over the latter?

 

Thanks,

Freddie

 

From: Andrew Waterman [mailto:andrew@...]
Sent: Friday, October 30, 2020 10:51 PM
To: Bill Huffman <huffman@...>
Cc: Jonathan Behrens <behrensj@...>; Xinhaoqu (Freddie) <xinhaoqu@...>; Andrea Mondelli <andrea.mondelli@...>; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Access unprivileged regions from OS

 

 

 

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

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

I'd tend to think that the user processes running under sPMP will have few enough data regions that software base-and-bounds checks on syscall arguments isn't prohibitively expensive.

 

      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


Re: Access unprivileged regions from OS

Andrew Waterman
 



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

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

I'd tend to think that the user processes running under sPMP will have few enough data regions that software base-and-bounds checks on syscall arguments isn't prohibitively expensive.

      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


Re: Access unprivileged regions from OS

Bill Huffman
 

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


Re: Access unprivileged regions from OS

Bill Huffman
 


On 10/30/20 3:25 PM, Andrew Waterman wrote:
EXTERNAL MAIL



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.
Yes, I overstated a bit.  But embedded address maps vary quite a bit more than Linux address maps.

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.

I have wondered whether we'd want a state bit, maybe in the security register, that said sstatus.sum meant data accesses were made as user rather than as either user or supervisor.

Or maybe the HLV*/HSV* instructions might be used more broadly for privilege control, not only with hypervisors.

     Bill


       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


Re: Access unprivileged regions from OS

Jonathan Behrens <behrensj@...>
 

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


Re: Access unprivileged regions from OS

Andrew Waterman
 



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


Re: Access unprivileged regions from OS

Bill Huffman
 


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


Re: Access unprivileged regions from OS

Andrew Waterman
 



On Fri, Oct 30, 2020 at 4:25 AM Andrea Mondelli <andrea.mondelli@...> wrote:



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.


My experience has been that, in the grand scheme of the cost of the syscall, the sstatus writes don't have a major effect on performance.  (Also, many syscalls don't need to access user memory, since args are passed and returned in registers; and many syscalls that do access user memory do so in bulk, amortizing the cost of the sstatus writes across many memory accesses, cache misses, etc.)

 

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?


At the time, we felt it was best to conserve opcode space and keep the ISA simpler.

(For somewhat different reasons, the hypervisor extension has chosen to add new instructions for accessing guest OS memory.)


Re: Access unprivileged regions from OS

Andrew Waterman
 



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.

 

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


Re: Access unprivileged regions from OS

Xinhao (Freddie) Qu
 

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


Re: Access unprivileged regions from OS

Andrea Mondelli <andrea.mondelli@...>
 



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?


Re: Access unprivileged regions from OS

Andrew Waterman
 



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


Access unprivileged regions from OS

Andrea Mondelli <andrea.mondelli@...>
 

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


Re: Unsupported counters in 'mcounteren'

Andrew Waterman
 



On Tue, Oct 27, 2020 at 2:53 PM Greg Favor <gfavor@...> wrote:
What is the architectural intention for a bit in 'mcounteren' that corresponds to an unsupported hpmcounter (i.e. the hpmcounter register is hardwired to zero)?  Can or should this counteren bit also be hardwired to zero, or must it still be writable by software (so as to allow U/S-mode software to read the hpmcounter register successfully and get a hardwired zero)?

The definitions for scounteren and hcounteren define these bits as WARL, clearly allowing them to be hardwired to 0.  But mcounteren in contrast does not declare these bits to be WARL.

mcounteren is WARL.  An editing error introduced this confusion earlier this year: https://github.com/riscv/riscv-isa-manual/commit/b3d494c7b2ef23dc57225eacd0ac0c165dfa1ddb -- which I'll fix now.


Greg


Unsupported counters in 'mcounteren'

Greg Favor
 

What is the architectural intention for a bit in 'mcounteren' that corresponds to an unsupported hpmcounter (i.e. the hpmcounter register is hardwired to zero)?  Can or should this counteren bit also be hardwired to zero, or must it still be writable by software (so as to allow U/S-mode software to read the hpmcounter register successfully and get a hardwired zero)?

The definitions for scounteren and hcounteren define these bits as WARL, clearly allowing them to be hardwired to 0.  But mcounteren in contrast does not declare these bits to be WARL.

Greg


Re: [RISC-V] [tech-cmo] Proposed CMO TG Charter

Guy Lemieux <guy.lemieux@...>
 

+1

On Fri, Oct 16, 2020 at 1:58 PM David Kruckemyer <dkruckemyer@...> wrote:
Hi all,

Andy and I would like to propose the following charter for the CMO TG for approval:

The Cache Maintenance Operation, or CMO, task group intends to define data cache maintenance operations for the RISC-V architecture, providing support for use-cases such as software-managed cache coherence, power management, persistent storage, security, and RAS. In the process, a data cache model will be developed, and the interactions of CMOs with the memory ordering model will be specified. In addition, the CMO specification will attempt to minimize the requirements on system design and will not prescribe a specific cache state model or cache coherence protocol. The CMO TG will coordinate with other RISC-V committees and task groups and with external parties to ensure consistency and interoperability with respect to any cache-related features and extensions.


Additional details on exact scope, goals, and roadmap will be outlined in a TG document that will be publicly available on GitHub. Please let us know if anyone has any questions or concerns.

Cheers,
David


Proposed CMO TG Charter

David Kruckemyer
 

Hi all,

Andy and I would like to propose the following charter for the CMO TG for approval:

The Cache Maintenance Operation, or CMO, task group intends to define data cache maintenance operations for the RISC-V architecture, providing support for use-cases such as software-managed cache coherence, power management, persistent storage, security, and RAS. In the process, a data cache model will be developed, and the interactions of CMOs with the memory ordering model will be specified. In addition, the CMO specification will attempt to minimize the requirements on system design and will not prescribe a specific cache state model or cache coherence protocol. The CMO TG will coordinate with other RISC-V committees and task groups and with external parties to ensure consistency and interoperability with respect to any cache-related features and extensions.


Additional details on exact scope, goals, and roadmap will be outlined in a TG document that will be publicly available on GitHub. Please let us know if anyone has any questions or concerns.

Cheers,
David

821 - 840 of 1210