1. Tech-Privileged
  2. Topics

MPIE and MPP update when returning from interrupt with MRET

Bill Huffman
 

When an exception or an ECALL arrives at its handler, the privilege of the code running before the exception/ECALL is always available in MPP or SPP.

 

      Bill

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Allen Baum
Sent: Tuesday, December 15, 2020 12:01 PM
To: Richard Trauben <rtrauben@...>
Cc: anne.merlande@...; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] MPIE and MPP update when returning from interrupt with MRET

 

EXTERNAL MAIL

This is in the priv spec sec 3.1.6.1 - just search for mret.

My explanation of why MPP reverts to Umode is to prevent privilege escalation if you go off the end of the 1-deep privilege level stack.

Whichever mode you return to, you can always set PP to either your own mode, or a lower priv level, but not higher, and this ensures it doesn't start out higher.

 

The absence of which mode you are in is quite deliberate: its existence is a virtualization hole.

 

On Tue, Dec 15, 2020 at 11:48 AM Richard Trauben <rtrauben@...> wrote:

privilege transitions from levels other than U  to a handler at levels other than M are certainly possible. 

 

*DELEG,*IE amd *EXCEPT will enable exception handler entry to non-M privilege moss handler and set the callera privilege level

in the *PP field to q non-U mode which calls the non-M mode handler.

 

Please provide the spec name, version, chapter, page, paragraph and sentence so an editor can consider details to clarify the reference. 

 

for me, the more problematic

issue was there was no psr

to identify the privilege of the

caller. technically however it is implicit and it’s assumed the code knows the privilege it was written for. it’s ok once you get used to the convention.

 

Richard

 

 



On Dec 15, 2020, at 7:18 AM, Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

Hello

The privileged architecture says that when returning from interrupt with MRET, MPIE is set to 1 (and MPP is set to U).
What is the rational behind ? Is it still in the context of supporting nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne

Allen Baum
 

This is in the priv spec sec 3.1.6.1 - just search for mret.
My explanation of why MPP reverts to Umode is to prevent privilege escalation if you go off the end of the 1-deep privilege level stack.
Whichever mode you return to, you can always set PP to either your own mode, or a lower priv level, but not higher, and this ensures it doesn't start out higher.

The absence of which mode you are in is quite deliberate: its existence is a virtualization hole.

On Tue, Dec 15, 2020 at 11:48 AM Richard Trauben <rtrauben@...> wrote:
privilege transitions from levels other than U  to a handler at levels other than M are certainly possible. 

*DELEG,*IE amd *EXCEPT will enable exception handler entry to non-M privilege moss handler and set the callera privilege level
in the *PP field to q non-U mode which calls the non-M mode handler.

Please provide the spec name, version, chapter, page, paragraph and sentence so an editor can consider details to clarify the reference. 

for me, the more problematic
issue was there was no psr
to identify the privilege of the
caller. technically however it is implicit and it’s assumed the code knows the privilege it was written for. it’s ok once you get used to the convention.

Richard




On Dec 15, 2020, at 7:18 AM, Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

Hello

The privileged architecture says that when returning from interrupt with MRET, MPIE is set to 1 (and MPP is set to U).
What is the rational behind ? Is it still in the context of supporting nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne

Richard Trauben
 

privilege transitions from levels other than U  to a handler at levels other than M are certainly possible. 

*DELEG,*IE amd *EXCEPT will enable exception handler entry to non-M privilege moss handler and set the callera privilege level
in the *PP field to q non-U mode which calls the non-M mode handler.

Please provide the spec name, version, chapter, page, paragraph and sentence so an editor can consider details to clarify the reference. 

for me, the more problematic
issue was there was no psr
to identify the privilege of the
caller. technically however it is implicit and it’s assumed the code knows the privilege it was written for. it’s ok once you get used to the convention.

Richard




On Dec 15, 2020, at 7:18 AM, Anne MERLANDE via lists.riscv.org <anne.merlande=st.com@...> wrote:

Hello

The privileged architecture says that when returning from interrupt with MRET, MPIE is set to 1 (and MPP is set to U).
What is the rational behind ? Is it still in the context of supporting nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne

Anne MERLANDE
 

Hello

The privileged architecture says that when returning from interrupt with MRET, MPIE is set to 1 (and MPP is set to U).
What is the rational behind ? Is it still in the context of supporting nested traps ? In case of an implementation with 2 privileged modes but no N extension is it still necessary ?

Thanks for your help
Anne

1 - 4 of 4