Where is the current privilege level stored?

[Matteo Zappia]

Good morning guys,
I am studying the RISC-V specifics on exception handling. I have read all the information about the CSRs involved during a trap. What I am missing is:

In which register is stored the privilege level at which the hart is running?

According to risc-v manual:

"At any time, a RISC-V hardware thread (hart) is running at some privilege level encoded as a mode in one or more CSRs. Three RISC-V privilege levels are currently defined.."

The only thing I found in CSRs is the xPP ( previous priority ) field in the mstatus, sstatus and ustatus register. 

Can someone help me?

Thank you in advance!

[Allen Baum]

The answer is that it isn't visible to running  code. That would defeat (if that's the correct word) virtualization. There should be no need for code to determine it's own mode.

-Allen

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/31fc5bec-fb4e-4e63-8107-32c135125ea2%40groups.riscv.org.

[Samuel Falvo II]

On Fri, Jul 20, 2018 at 8:08 AM, Allen Baum
<allen...@esperantotech.com> wrote:
> The answer is that it isn't visible to running code. That would defeat (if
> that's the correct word) virtualization. There should be no need for code to
> determine it's own mode.

I'd like to add on to this.

Another thing to consider: let's suppose that you *do* succeed in
virtualizing a hart that exposes the current privilege level, what
you'll find is that the "current virtual privilege mode" is *always*
set to the same value for a given piece of code. That is, the trap
handler responding to M-mode traps will always have the privilege set
to 11, the S-mode trap handler (whatever is pointed at by stvec) will
always see mode 01, and so forth. With the privilege effectively
being constant for a given chunk of code, not recording it in xSTATUS
frees up two bits that are better used for other things.

I remember asking the same thing some years ago here, because I wanted
to write a debugger interface which printed the current privilege mode
of the running program, and was given an answer similar to Allen's. I
was skeptical, but as I wrote the code, I started to realize that to
provide the diagnostic display I wanted, I *only* relied on the MPP
field, and never on any other. The code I'd written *always* ran at
M-mode, so it didn't make sense to query the current privilege mode.

If you've written a procedure or function which can be called from a
plurality of privilege levels, then you've exposed yourself to a
possible vector for compromise. My recommendation would be to either
replicate the code (so one procedure for M-mode, one for S-mode, one
for U-mode, etc), *or*, write the common procedure such that it *only*
ever assumes its running in U-mode. With strong pressure to isolate
S-mode and U-mode address spaces anyway, even this latter strategy may
have implications that would be wise to question.


--
Samuel A. Falvo II

[Luke Kenneth Casson Leighton]

On Friday, July 20, 2018, Samuel Falvo II <sam....@gmail.com> wrote:

for U-mode, etc), *or*, write the common procedure such that it *only*
ever assumes its running in U-mode.  With strong pressure to isolate
S-mode and U-mode address spaces anyway, even this latter strategy may
have implications that would be wise to question.

In other words if you have control of the machine you control what the trap addresses are, therefore implicitly you know that if that code is called you must be in the state associated with it.

If however the same trap is called from two different modes or calls code that is used in different modes then that implicit state is lost.

For security in VM scenarios that is actually desirable.

I would tend to agree with Samuel that even providing information about the previous state is... should have really, really good reasons why it is available.

L.

--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68