CHERI when RISC-V XLEN changes

[andresag01]

RISC-V has a feature that allows implementations to configure the ISA variant in use: 32-bit, 64-bit or 128-bit. The configuration is through the misa register and the RISC-V Privileged Specification describes it like this:

The MXL (Machine XLEN) field encodes the native base integer ISA width as shown in Table 9. The MXL field may be writable in implementations that support multiple base ISAs. The effective XLEN in M-mode, MXLEN, is given by the setting of MXL, or has a fixed value if misa is zero. The MXL field is always set to the widest supported ISA variant at reset.

And there are analogous fields in mstatus for Supervisor and User modes (see SXL and UXL).

How does CHERI work when the XLEN changes in RISC-V? Is it expected that, for example, the same capability encoding is kept but the address field is just smaller?

[jrtc27]

The expectation is you don't get CHERI whilst in a mode with XLEN < MAX_MXL, i.e. emulating a 32-bit core on a 64-bit core gets you just the 32-bit compatibility, or possibly that you get the corresponding capability format(*). Having a 128-bit capability format with RV32 would be a cursed configuration that you couldn't have otherwise exist.

(*) This poses issues for memcpy though, since you can no longer do a capability-oblivious memcpy unless you further extend CHERI to allow for it (your 64-bit OS would need to preserve 64-bit and 128-bit capabilities' tags, but they're different types and have different strides). You could come up with schemes to do so, but none have been prototyped. Given that CHERI on RV32 exists solely for the embedded space (the lack of page table bits means you can't do a full Unix, and the lack of precision bits likely causes compatibility issues with applications-class server stacks) this is not expected to be an issue.

[tariqkurd-repo]

RISC-V requires extensions to support variable MXLEN/SXLEN/UXLEN, apparently with any combinations possible:

To reduce hardware complexity, the architecture imposes no checks that lower-privilege modes have XLEN settings less than or equal to the next-higher privilege mode. In practice, such settings would almost always be a software bug, but machine operation is well-defined even in this case.

For CHERI this doesn't make much sense, U-mode RV32 CHERI and S-mode RV64 CHERI cannot share capabilities. We can cleanly define that:

. Higher privilege levels must have the same XLEN or be wider than lower privilege levels . Any privilege level with less than maximum XLEN cannot have CHERI enabled

Then DDC/PCC are the maximum width and checks can be enforced on load/store and instruction fetch. MTCC/MEPC will be for RV64, but with sign extended PCs for RV32 lower privileges.

CHERI can't obviously support the full set of variable XLEN values as the interpretatoin of the metadata is RV64/RV32 specific. I don't know if RISC-V extensions can restrict the rules. My hope is that my having a global CHERI enable which is disabled on reset, then we can say that when CHERI is enabled the dynamic values of MXL/SXL/UXL can be restricted. We'll have to test this theory.

[jrtc27]

There’s no reason to restrict the xXL values; you get what you ask for.

[jrtc27]

And I still do not want a global CHERI enable. It does not solve the problem you think it solves, and should not be needed if we get the architecture right. If we need it then we’ve got the architecture wrong.