Explicit separation between privileged and unprivileged ISAs

[jasonyu1996]

Hi folks!

I'm thinking that it might be a good idea to split the core extension into separate unprivileged and privileged parts. RISC-V itself has this split. The instruction set manual has two volumes which cover unprivileged and privileged ISAs separately, and in Introduction of the second volume:

We briefly note that the entire privileged-level design described in this document could be replaced with an entirely different privileged-level design without changing the unprivileged ISA, and possibly without even changing the ABI. In particular, this privileged specification was designed to run existing popular operating systems, and so embodies the conventional level-based protection model. Alternate privileged specifications could embody other more flexible protection-domain models. For simplicity of expression, the text is written as if this was the only possible privileged architecture.

In other words, the unprivileged RISC-V ISA is designed to be useful for alternative privileged-level designs. A custom system can choose to use only the unprivileged ISA and either leave out the privileged ISA or use a custom-designed one.

Correspondingly, the same can be done to CHERI. The most essential part of CHERI capabilities, e.g., capability encodings, bounds checking, and instructions that handle them, is useful irrespective of privileged-level design of the system. As suggested in #4 one can even design a system where capability-based protection subsumes traditional protection rings. Splitting the core extension thus enables the capability design to be more generally applicable.

Maybe this split is already there, but it is implicit in the current draft. The opening paragraph of Chapter 3 mentions that the described changes are for both the unprivileged and privileged components:

The remainder of this chapter describes these changes for both the unprivileged and privileged components of the base integer RISC-V ISAs.

If this is the case, I suggest reorganising Chapter 3 to make the separation more explicit. Perhaps it is a good idea to include a brief note like the one in the RISC-V Instruction Set Manual too.

Please let me know what you think.

[andresag01]

@jasonyu1996 : The current CHERI RISC-V specification is not meant to be a monolithic block that must be implemented in its entirety and neither does it intend to deprecate original goals of the RISC-V spec like the one you pointed out. In this sense, you could opt to implement the unprivileged part of the CHERI RISC-V spec and pair it with a different privileged spec that also integrates with CHERI. I do not see any limitations in this regard in the current spec.

I guess you are referring to the current Chapter 3 that describes how CHERI integrates with the unprivileged and privileged spec as well as the debug spec. Again, having the write up all in one chapter was just for convenience and the split in sections highlights which parts of the RISC-V spec the text corresponds to.

The point you are making could be clarified, perhaps adding a paragraph somewhere towards the beginning of Chapter 3. However, I do not see many advantages to changing the current structure of Chapter 3. Do you think that there is a problem/limitation in the current CHERI RISC-V spec that this would solve or is the change purely for readability?

[jasonyu1996]

@jasonyu1996 : The current CHERI RISC-V specification is not meant to be a monolithic block that must be implemented in its entirety and neither does it intend to deprecate original goals of the RISC-V spec like the one you pointed out. In this sense, you could opt to implement the unprivileged part of the CHERI RISC-V spec and pair it with a different privileged spec that also integrates with CHERI. I do not see any limitations in this regard in the current spec.

I guess you are referring to the current Chapter 3 that describes how CHERI integrates with the unprivileged and privileged spec as well as the debug spec. Again, having the write up all in one chapter was just for convenience and the split in sections highlights which parts of the RISC-V spec the text corresponds to.

The point you are making could be clarified, perhaps adding a paragraph somewhere towards the beginning of Chapter 3. However, I do not see many advantages to changing the current structure of Chapter 3. Do you think that there is a problem/limitation in the current CHERI RISC-V spec that this would solve or is the change purely for readability?

Thanks for clarifying that CHERI RISC-V is already intended to enable such a split. Previously I was not so sure that this was the case, so I started this thread to enquire about it and suggest enabling such a split if it was not already so.

I don't have specific technical problems to report yet, and will report them separately if I find any. I do think the point about supporting this split can be clarified for readability, perhaps by

• As you mentioned, adding a paragraph similar to the one at the beginning of Volume 2 of the base RISC-V spec
• Small organisational adjustments like grouping sections of Chapter 3 into the unprivileged and privileged parts, mirroring the two-volume split in the base spec

[andresag01]

@jasonyu1996 : Thank you for your question. Would you like to create PRs for this if its something that you think should be included in the spec?

[jasonyu1996]

@jasonyu1996 : Thank you for your question. Would you like to create PRs for this if its something that you think should be included in the spec?

Thanks! Yes I am going to take a shot then.

[andresag01]

@jasonyu1996 : Thank you for your question. Would you like to create PRs for this if its something that you think should be included in the spec?

Thanks! Yes I am going to take a shot then.

Thanks! I recommend making small changes incrementally in separate PRs as they get merged. This is so that it is more manageable for the community to review them and to ensure that others are aligned with your idea before too much time is invested into the change.

[tariqkurd-repo]

Hold on here - the RISC-V ISA spec is being merged into one document - as the split is unhelpful and confusing. This was announced at the recent summit in Munich. I am not convinced that you can have the RISC-V unprivileged architecture with a separate privilege architecture - where does it state that this is possible?

At the moment we are trying to get the spec reviewed by RISC-V management, re-organising it at this time is unlikely to be helpful, I think it's more productive to have a list of requirements (i.e. this issue) to take into account when we get official RISC-V feedback.

As I say - I don't believe unpriv and priv are seperable now or in the future.

[jasonyu1996]

Hold on here - the RISC-V ISA spec is being merged into one document - as the split is unhelpful and confusing. This was announced at the recent summit in Munich. I am not convinced that you can have the RISC-V unprivileged architecture with a separate privilege architecture - where does it state that this is possible?

At the moment we are trying to get the spec reviewed by RISC-V management, re-organising it at this time is unlikely to be helpful, I think it's more productive to have a list of requirements (i.e. this issue) to take into account when we get official RISC-V feedback.

As I say - I don't believe unpriv and priv are seperable now or in the future.

Thanks for the comment! I was honestly not aware of the decision to merge the two parts as I didn't go to Munich. Could you point me to some related materials?

[tariqkurd-repo]

I don't have any related material, and it looks like the latest release still has separate priv and unpriv: https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-isa-release-568e50a-2024-07-12
But Krste announced a single manual correctly merged with useful cross-references in Munich.
I don't know when that will be released.

[davidchisnall]

There's a difference between a single manual and a single non-decomposable ISA. The unprivileged spec manual describes several extensions which can be implemented, not implemented, or replaced with others. This has been a key principle of RISC-V for at least as long as I've been involved (ten years now).

The privileged extensions (S*) are not special in this regard, unless explicitly stated somewhere.

[jasonyu1996]

There's a difference between a single manual and a single non-decomposable ISA. The unprivileged spec manual describes several extensions which can be implemented, not implemented, or replaced with others. This has been a key principle of RISC-V for at least as long as I've been involved (ten years now).

The privileged extensions (S*) are not special in this regard, unless explicitly stated somewhere.

Agreed.

The issues seems to boil down to whether this announced change is about making the unprivileged/privileged components inseparable or simply merging two documents. As I understand it, the current spec states that the unprivileged design can be used with an entirely different privileged design. If this is to change, I wonder what the rationale is. The unprivileged ISA seems generic enough to be usable for alternative privileged designs.

[tariqkurd-repo]

As I understand it, the current spec states that the unprivileged design can be used with an entirely different privileged design.

where does it say this? Have you got a reference?

[davidchisnall]

where does it say this? Have you got a reference?

That's not the way RISC-V works. Any extension is optional. Extensions that depend on other extensions are explicitly documented as doing so. The S family of extensions is not special in this regard.

There are (or, at least, will be) profiles / platforms that mandate specific sets of extensions. You cannot replace the privileged extension with something custom and still comply with a profile or platform that mandates it, but you can easily replace it with something else if you don't claim such compliance.

Radix trees are a spectacularly bad way of doing virtual memory for modern workloads, they're in RISC-V for two reasons:

• The RISC-V policy of not shipping research in standards.
• The fact that Linux really, really assumes that virtual memory is managed by radix trees and is a pain to port to other approaches.

It was never intended that this would be the only way of doing virtual memory on RISC-V and some research groups have already built prototypes exploring better approaches.

[jasonyu1996]

As I understand it, the current spec states that the unprivileged design can be used with an entirely different privileged design.

where does it say this? Have you got a reference?

I'm not sure if I paraphrased it in a wrong way but I was referring to Chapter 1 of Volume II:

We briefly note that the entire privileged-level design described in this document could be replaced with an entirely different privileged-level design without changing the unprivileged ISA, and possibly without even changing the ABI. In particular, this privileged specification was designed to run existing popular operating systems, and so embodies the conventional level-based protection model. Alternate privileged specifications could embody other more flexible protection-domain models. For simplicity of expression, the text is written as if this was the only possible privileged architecture.