Tighten up rules around CRE and CME

[tariqkurd-repo]

My interpretation of the current rules for enabling CHERI registers / CHERI mode at different privilege levels:

If mseccfg.CME==0

• Xenvcfg.CRE=0
• Xenvcfg.CME=0

else if menvcfg.CRE==0

• menvcfg.CME=0
• senvcfg.CRE=0
• senvcfg.CME=0

else if menvcfg.CME==0

• senvcfg.CRE=0
• senvcfg.CME=0

else if senvcfg.CRE==0

• senvcfg.CME=0

Two implementations here:

1. multi-CSR WARL field
2. the bits read as zero, but the underlying state doesn't change

The difference being whether (e.g.) toggling mseccfg.CME causes the other bits to actually be set to zero in the registers, or just read as zero so we're infering AND gates on the read paths, not changing the register state.

I prefer 2 but i'm not sure there's a precedence for that in RISC-V

Also

RV64 only: if UXLEN < MXLEN then senvcfg.CRE=0
RV64 only: if SXLEN < MXLEN then menvcfg.CRE=0

so again, do we actually clear the register bits or AND the read data to set CRE to zero.

Opinions? @sorear ?

The current text says CRE is read-only zero if menvcfg.CRE=0 but it doesn't say if the underlying register state is cleared or not.

[andresag01]

Based on the discussion here, those configuration bits are as follows:

• CRE: Enable access to CHERI instructions, CHERI CSR state and forces mode=Legacy if CRE=0
• CME: In Zcheri_legacy, indicates the current mode.

The allowed combinations are like this:

• CRE=0 then CME=? (i.e. CME is don't care) => Legacy mode and the machine behaves like standard RISC-V + CHERI checks
• CRE=1 && CME=0 => Legacy mode and the extra CHERI instructions/CSRs are available
• CRE=1 && CME=1 => Purecap

Its worth discussing what happens to the other bits when CRE or CME are 0/1 e.g. when menvcfg changes to a value that contradicts senvcfg. Other than the options listed in your comment, it is also possible to throw an exception when you try executing in a mode (e.g. S mode) with state that contradicts a more privileged mode (e.g. if menvcfg.CME contradicts senvcfg.CME) although this kind of behaviour is generally avoided in RISC-V

[tariqkurd-repo]

The current thinking is:

If menvcfg.CRE=0 then senvcfg.CRE and senvcfg.CME are both set to zero - including in the register state

otherwise the controls can be programmed freely, although we're going to consider CME, CRE as a 2-bigt WARL field, so that the case of CRE=0, CME=1 becomes illegal

[andresag01]

In the discussion, it also came up that we would like the CME bits to be independent controls across the privilege levels, so menvcfg.CME=0 does not force senvcfg.CME=0.

[tariqkurd-repo]

#126

[sorear]

CRE is intended as a transitional mechanism. I expect to dramatically change the rules in 1-2 weeks, rendering anything done on it in the meantime wasted effort.

[andresag01]

A PR was merged to fix this, so I will close the ticket.