consider including Zcherilevels in the base ISA

[tariqkurd-repo]

We'll have an easier time with the CHERI ratification if we include Zcherilevels in the base ISA.
In general reducing options is good.

Is there any reason not to just include it?

Do we think the spec is mature enough? The hardware cost is very low.

Is ti similar enough to the version in CHERIoT for us to have confidence that it's correct, and also we have several months until spec freeze - so we still have time to find and address any issues.

#565 is onle example of the awkwardness caused by having it optional. I think we'll find many more cases as the ratificaiton and software development processes continue, not least from the complexity of the documentation.

However - how confident are we that it can extend to multi-level correctly with the current spec?

[nwf]

FWIW, the comparison to CHERIoT and research-CHERI only for the two-level version. In particular, AFAIK, there has been no work demonstrating the practical sensibility/utility/viability of multi-level schemes.

From hallway chatter that I recall, there's at least suspicion that a linear ordering of levels is perhaps not the right one, or not the only one, that we will want; it seems at least moderately likely that software will want orthogonal L/G-like IFC (candidates include kernel-/user-space caps and a distinction between (un)managed heap memories).

[jrtc27]

It is not clear that every implementation will want a level scheme that looks like this (or a clean extension thereof). Making it optional allows its omission or replacement in such environments.

[tariqkurd-repo]

This is true - but it means we may have to ratify twice - once without it and then again for the extension.
We need to get a 100% perfect description of the ISA into the RISC-V ISA manual.
If we omit Zcherilevels, then we'll have to do that work again with it included, which will be effort, and requires review etc.

We can omit it, but it will be a lot more work to add it later than just to include it.

There'll definitely be two versions of the ACPERM instruction, for example, as Zcherilevels redefines the rules for removing permissions.

Also ACPERM will be problematic in the RISC-V ISA Manual because we want to keep the encoding format separate, probably in an appendix, so it will need a generic description in the base ISA and then specialisation in the appendix along with the format(s) I think.

ACPERM, GCPERM, SCBLD, SCSS, LC, SC are all affected and will need spec updates if we keep the extension separate.