RISC-V Specification for CHERI Extensions

There are RISC-V extensions in development that may duplicate some aspects of CHERI functionality or directly conflict with CHERI and should only be available in Integer Pointer Mode on a CHERI-enabled hart. These include:

The tag is an additional hardware managed bit added to addressable memory and registers. It is stored separately and may be referred to as "out of band". It indicates whether a register or CLEN-aligned memory location contains a valid capability. If the tag is set, the capability is valid and can be dereferenced (contingent on checks such as permissions or bounds).

The capability is invalid if the tag is clear. Using an invalid capability to dereference memory or authorize any operation gives rise to exceptions. All capabilities derived from invalid capabilities are themselves invalid i.e. their tags are 0.

All locations in registers or memory able to hold a capability are CLEN+1 bits wide including the tag bit. Those locations are referred as being CLEN-bit or capability wide in this specification.

The byte-address of a memory location is encoded as MXLEN integer value.

A bit vector used by the kernel or application programs for software-defined permissions (SDP).

This bit indicates the type of the capability: it is a sealed capability if the bit is 1 or unsealed if it is 0.

Sealed capabilities (CT ≠ 0 ) cannot be dereferenced to access memory and are immutable such that modifying any of its fields clears the tag of the output capability.

For code capabilities, the sealing bit is used to implement immutable capabilities that describe function entry points, known as sealed entry (sentry) capabilities. Such capabilities can be leveraged to establish a form of control-flow integrity between mutually distrusting code. A program may jump to a sentry capability to begin executing the instructions it references. A JALR instruction with zero offset automatically unseals a sentry target capability and installs it in the program counter capability (see Section 4.2). The jump-and-link instructions also seal the return address capability which serves as an entry point the callee can return to but cannot use to authorize memory loads or stores.

The NULL capability is represented with 0 in all fields. This implies that it has no permissions and its exponent E is CAP_MAX_E (52 for MXLEN=64, 24 for MXLEN=32), so its bounds cover the entire address space such that the expanded base is 0 and top is 2^MXLEN.

¹ This field only exists if Zcherilevels is implemented.

The Infinite capability grants all permissions while its bounds also cover the whole address space. It includes X-permission and so includes the CHERI Execution Mode Encoding if Zcherihybrid is supported.

¹If Zcherihybrid is supported, then the Infinite capability must represent Integer Pointer Mode for compatibility with standard RISC-V code. Therefore:

² This field only exists if Zcherilevels is implemented.

The new address, after updating the address of a capability, is within the representable range if decompressing the capability’s bounds with the original and new addresses yields the same base and top addresses.

In other words, given a capability with address a and the new address a' = a + x, the bounds b and t are decoded using a and the new bounds b' and t' are decoded using a'. The new address is within the capability’s representable range if b == b' && t == t'.

Changing a capability’s address to a value outside the representable range unconditionally clears the capability’s tag. Examples are:

In the bounds encoding in this specification, the top and bottom capability bounds are formed of two or three sections:

The top described by Table 13 is MXLEN+1 bits wide to allow capabilities to span the whole address space. The address is zero-extended by one bit. The malformed check (see Section 3.2.6.3) ensures that the top never overflows into MXLEN+2 bits and that the base never overflows into MXLEN+1 bits.

The representable range defines the range of addresses which do not corrupt the bounds encoding. The encoding was first introduced in Section 3.1, and is repeated in a different form in Table 13 to aid this description.

For the address to be valid for the current bounds encoding, the value in the Upper Section of Table 13 must not change as this will change the meaning of the bounds.

This gives a range of s=2E+MW, as shown in Figure 3.

The gap between the object bounds and the bound of the representable range is always guaranteed to be at least 1/4 of s. This is represented by R = B - 2MW-2 in Section 3.1. This gives useful guarantees, such that if an executed instruction is in pcc bounds, then it is also guaranteed that the next linear instruction is representable.

An authorizing capability with appropriate permissions is required to execute instructions in Zcheripurecap. Therefore, the unprivileged program counter (pc) register is extended so that it is able to hold a capability. The extended register is called the program counter capability (pcc). The pcc address field is effectively the pc in the base RISC-V ISA so that the hardware automatically increments as instructions are executed. The pcc's metadata and tag are reset to the Infinite capability metadata and tag with the address field set to the core boot address.

The hardware performs the following checks on pcc for each instruction executed in addition to the checks already required by the base RISC-V ISA. A failing check causes a CHERI exception.

pcc is an executable vector, so it need not be able to hold all possible invalid addresses.

These instructions allow software to inspect the fields of a capability held in a c register. The output is an integer value written to an x register representing the decoded field of the capability, such as the permissions or bounds. These instructions do not cause exceptions.

These instructions allow software to manipulate the fields of a capability held in a c register. The output is a capability written to a c register with its fields modified. The output capability has its tag set to 0 if the input capability did not have a tag set, the output capability has more permissions or larger bounds compared to the input capability, or the operation results in a capability with malformed bounds. These instructions do not give rise to exceptions.

A load capability instruction, LC, reads CLEN bits from memory together with its tag and writes the result to a c register. The capability authorizing the memory access is provided in a c source register, so the effective address is obtained by incrementing that capability with the sign-extended 12-bit offset.

A store capability instruction, SC, writes CLEN bits and the tag in a c register to memory. The capability authorizing the memory access is provided in a c source register, so the effective address is obtained by incrementing that capability with the sign-extended 12-bit offset.

LC and SC instructions cause CHERI exceptions if the authorizing capability fails any of the following checks:

Capability load and store instructions also cause load or store/AMO address misaligned exceptions if the address is not naturally aligned to a CLEN boundary.

Misaligned capability loads and stores are errors. Implementations must generate exceptions for misaligned capability loads and stores even if they allow misaligned integer loads and stores to complete normally. Execution environments must report misaligned capability loads and stores as errors and not attempt to emulate them using byte access. The Zicclsm extension does not affect capability loads and stores. Software which uses capability loads and stores to copy data other than capabilities must ensure that addresses are aligned.

For loads, the tag of the capability loaded from memory is cleared if the authorizing capability does not grant permission to read capabilities (i.e. both R-permission and C-permission must be set in AP). For stores, the tag of the capability written to memory is cleared if the authorizing capability does not grant permission to write capabilities (i.e. both W-permission and C-permission must be set in AP).

Most integer computational instructions operate on XLEN bits of values held in x registers. Therefore, these instructions only operate on the address field if the input register of the instruction holds a capability. The output is XLEN bits written to an x register; the tag and capability metadata of that register are zeroed.

The add upper immediate to pcc instruction (AUIPC) is used to build pcc-relative capabilities. AUIPC forms a 32-bit offset from the 20-bit immediate and filling the lowest 12 bits with zeros. The pcc address is then incremented by the offset and a representability check is performed so the capability’s tag is cleared if the new address is outside the pcc's Representable Range. The resulting CLEN value along with the new tag are written to a c register.

Control transfer instructions operate as described in the base RISC-V ISA. They also may cause metadata updates and/or cause exceptions in addition to the base behavior as described below.

Integer load and store instructions transfer the amount of integer data described in the base RISC-V ISA between the registers and memory. For example, LD and LW load 64-bit and 32-bit values respectively from memory into an x register. However, the address operands for load and store instructions are interpreted differently in Zcheripurecap: the capability authorizing the access is in the c register operand and the memory address is given by incrementing the address of that capability by the sign-extended 12-bit immediate offset.

All load and store instructions cause CHERI exceptions if the authorizing capability fails any of the following checks:

Integer load instructions always zero the tag and metadata of the result register.

Integer stores write zero to the tag associated with the memory locations that are naturally aligned to CLEN. Therefore, misaligned stores may clear up to two tag bits in memory.

All CSR instructions atomically read-modify-write a single CSR. If the CSR accessed is of capability size then the capability’s tag, metadata and address are all accessed atomically.

When the CSRRW instruction is accessing a capability width CSR, then the source and destination operands are c registers and it atomically swaps the values in the whole CSR with the CLEN width register operand.

There are special rules for updating specific CLEN-wide CSRs as shown in Table 49.

When CSRRS and CSRRC instructions are accessing a capability width CSR, such as mtvecc, then the destination operand is a c register and the source operand is an x register. Therefore, the instructions atomically read CLEN bits from the CSR, calculate the final address using standard RISC-V behavior (set bits, clear bits, etc.), and that final address is written to the CSR capability’s address field. The update typically uses the semantics of a SCADDR instruction which clears the tag if the capability is sealed, or if the updated address is not representable. Table 49 shows the exact action taken for each capability width CSR.

The CSRRWI, CSRRSI and CSRRCI variants are similar to CSRRW, CSRRS, and CSRRC respectively, when accessing a capability width CSR except that they update the capability’s address only using an XLEN-bit value obtained by zero-extending a 5-bit unsigned immediate field.

All CSR instructions cause CHERI exceptions if the pcc does not grant ASR-permission and the CSR accessed is privileged.

The mstatus and mstatush registers operate as described in (RISC-V, 2023) except for the SXL and UXL fields that control the value of XLEN for S-mode and U-mode, respectively, and the MBE, SBE, and UBE fields that control the memory system endianness for M-mode, S-mode, and U-mode, respectively.

The encoding of the SXL and UXL fields is the same as the MXL field of misa. Only 1 and 2 are supported values for SXL and UXL and the fields must be read-only in implementations supporting Zcheripurecap. The effective XLEN in S-mode and U-mode are termed SXLEN and UXLEN, respectively.

The MBE, SBE, and UBE fields determine the endianness of memory accesses other than instruction fetches performed from M-mode, S-mode, or U-mode, respectively. xBE=0 indicates little endian and xBE=1 is big endian. MBE must be read-only. SBE and UBE must be read only and equal to MBE, if S-mode or U-mode, respectively, is implemented, or read-only zero otherwise.

The mtvec register is as defined in (RISC-V, 2023). It is an MXLEN-bit register used as the executable vector jumped to when taking traps into machine mode. It is extended into mtvecc.

The mtvecc register is a renamed extension of mtvec that holds a capability. Its reset value is the Infinite capability. The capability represents an executable vector.

The metadata is WARL as not all fields need to be implemented, for example the reserved fields will always read as zero.

When interpreting mtvecc as a capability, as for mtvec, address bits [1:0] are always zero (as they are reused by the MODE field).

When MODE=Vectored, all synchronous exceptions into machine mode cause the pcc to be set to the capability, whereas interrupts cause the pcc to be set to the capability with its address incremented by four times the interrupt cause number.

Capabilities written to mtvecc also include writing the MODE field in mtvecc.address[1:0]. As a result, a representability and sealing check is performed on the capability with the legalized (WARL) MODE field included in the address. The tag of the capability written to mtvecc is cleared if either check fails.

Additionally, when MODE=Vectored the capability has its tag bit cleared if the capability address + 4 x HICAUSE is not within the representable bounds. HICAUSE is the largest exception cause value that the implementation can write to mcause when an interrupt is taken.

The mscratch register is as defined in (RISC-V, 2023). It is an MXLEN-bit read/write register dedicated for use by machine mode. Typically, it is used to hold a pointer to a machine-mode hart-local context space and swapped with a user register upon entry to an M-mode trap handler. mscratch is extended into mscratchc.

The mscratchc register is a renamed extension of mscratch that is able to hold a capability.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

It is not WARL, all capability fields must be implemented.

The mepc register is as defined in (RISC-V, 2023). It is extended into mepcc.

The mepcc register is a renamed extension of mepc that is able to hold a capability. Its reset value is the Infinite capability.

Capabilities written to mepcc must be legalized by implicitly zeroing bit mepcc[0]. Additionally, if an implementation allows IALIGN to be either 16 or 32, then whenever IALIGN=32, the capability read from mepcc must be legalized by implicitly zeroing mepcc[1]. Therefore, the capability read or written has its tag bit cleared if the legalized address is not within the Representable Range or if the legalization changes the address and the capability is sealed.

When a trap is taken into M-mode, mepcc is written with the pcc including the virtual address of the instruction that was interrupted or that encountered an exception. Otherwise, mepcc is never written by the implementation, though it may be explicitly written by software.

As shown in Table 51, mepcc is an executable vector, so it does not need to be able to hold all possible invalid addresses. Additionally, the capability in mepcc is unsealed when it is installed in pcc on execution of an MRET instruction.

Zcheripurecap adds a new exception code for CHERI exceptions that mcause must be able to represent. The new exception code and its priority are listed in Table 19 and Table 20 respectively. The behavior and usage of mcause otherwise remains as described in (RISC-V, 2023).

¹ The higher priority CHERI PTE page fault covers capability loads or atomics where the loaded tag is not checked, and all capability stores and atomics where the stored tag is set.

² CHERI PTE page fault exceptions have the same priority against access faults as normal RISC-V page faults. If a normal RISC-V page fault and a CHERI PTE fault are both detected simultaneously, then both are recorded as shown in Table 23.

³ The lower priority PTE fault only covers capability loads and atomics where the loaded tag is checked.

Bit 28 of medeleg now refers to a valid exception and so can be used to delegate CHERI exceptions to supervisor mode.

The mtval register is an MXLEN-bit read-write register formatted as shown in Figure 12. When a data memory access gives rise to a CHERI fault taken into M-mode, mtval is written with the MXLEN-bit effective address which caused the fault according to the existing rules for reporting load/store addresses from (RISC-V, 2023). In this case the TYPE field of mtval2 shown in Table 21 is set to 1. For all other CHERI faults mtval is set to zero.

The behavior of mtval is otherwise as described in (RISC-V, 2023).

If the hardware platform specifies that no exceptions set mtval to a non-zero value, then mtval is read-only zero for all CHERI exceptions.

The mtval2 register is an MXLEN-bit read-write register, which is added as part of the Hypervisor extension (RISC-V, 2023). Zcheripurecap also requires the implementation of this CSR.

When a CHERI fault is taken into M-mode, mtval2 is written with additional CHERI-specific exception information with the format shown in Figure 13 to assist software in handling the trap.

If mtval is read-only zero for CHERI exceptions then mtval2 is also read-only zero for CHERI exceptions.

The stvec register is as defined in (RISC-V, 2023). It is an SXLEN-bit register used as the executable vector jumped to when taking traps into supervisor mode. It is extended into stvecc.

The stvec register is an SXLEN-bit WARL read/write register that holds the trap vector configuration, consisting of a vector base address (BASE) and a vector mode (MODE). The stvecc register is a renamed extension of stvec that is able to hold a capability. Its reset value is the Infinite capability.

The handling of stvecc is otherwise identical to mtvecc, but in supervisor mode.

The sscratch register is as defined in (RISC-V, 2023). It is an MXLEN-bit read/write register dedicated for use by supervisor mode. Typically, it is used to hold a pointer to a supervisor-mode hart-local context space and swapped with a user register upon entry to an S-mode trap handler. sscratch is extended into sscratchc.

The sscratchc register is a renamed extension of sscratch that is able to hold a capability.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

It is not WARL, all capability fields must be implemented.

The sepc register is as defined in (RISC-V, 2023). It is extended into sepcc.

The sepcc register is a renamed extension of sepc that is able to hold a capability. Its reset value is the Infinite capability.

As shown in Table 51, sepcc is an executable vector, so it need not be able to hold all possible invalid addresses. Additionally, the capability in sepcc is unsealed when it is installed in pcc on execution of an SRET instruction. The handling of sepcc is otherwise identical to mepcc, but in supervisor mode.

Zcheripurecap adds a new exception code for CHERI exceptions that scause must be able to represent. The new exception code and its priority are listed in Table 24 and Table 20 respectively. The behavior and usage of scause otherwise remains as described in (RISC-V, 2023).

The stval register is an SXLEN-bit read-write register formatted as shown in Figure 21.

stval is updated following the same rules as mtval for CHERI exceptions which are delegated to S-mode.

The stval2 register is an SXLEN-bit read-write register, which is added as part of Zcheripurecap when the implementation supports S-mode. Its CSR address is 0x14b.

stval2 is updated following the same rules as mtval2 for CHERI exceptions which are delegated to S-mode.

The fields are identical to mtval2 for CHERI exceptions, and for load and store/AMO page fault exceptions if Zcheripte is implemented.

When address translation is in effect and XLEN=64, the upper bits of virtual memory addresses must match for the address to be valid:

RISC-V permits that CSRs holding addresses, such as mtvec and mepc (see Table 51) as well as pc, need not hold all possible invalid addresses. Implementations may convert an invalid address into some other invalid address that the register is capable of holding. Therefore, implementations often support area and power optimizations by compressing invalid addresses in a lossy fashion.

Where compressed addresses are implemented, there must be also sufficient address bits to represent all valid physical addresses. The following description is for both virtual and physical addresses.

However, the bounds encoding of capabilities in Zcheripurecap depends on the address value, so implementations must not convert invalid addresses to other arbitrary invalid address in an unrestricted manner. The remainder of this section describes how invalid address handling must be supported in Zcheripurecap when accessing CSRs, branching and jumping, and accessing memory.

When executing code due to an abstract command, the hart stays in debug mode and the rules outlined in Section 4.1 of (RISC-V, 2022) apply.

Zcheripurecap renames and extends debug CSRs that are designated to hold addresses to be able to hold capabilities. The renamed debug CSRs are listed in Table 14.

The pcc must grant ASR-permission to access debug CSRs. This permission is automatically provided when the hart enters debug mode as described in the dpcc section. The pcc metadata can only be changed if the implementation supports executing control transfer instructions from the program buffer — this is an optional feature according to (RISC-V, 2022).

The dpc register is as defined in (RISC-V, 2022). It is a DXLEN-bit register used as the PC saved when entering debug mode. dpc is extended into dpcc.

The dpcc register is a renamed extension to dpc that is able to hold a capability.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

Upon entry to debug mode, (RISC-V, 2022), does not specify how to update the PC, and says PC relative instructions may be illegal. This concept is extended to include any instruction which reads or updates pcc, which refers to all jumps, conditional branches and AUIPC. The exceptions are MODESW.CAP and MODESW.INT which are supported if Zcherihybrid is implemented, see dinfc for details.

As a result, the value of pcc is UNSPECIFIED in debug mode according to this specification. The pcc metadata has no architectural effect in debug mode. Therefore ASR-permission is implicitly granted for access to all CSRs and no CHERI instruction fetch faults are possible.

dpcc (and consequently dpc) are updated with the capability in pcc whose address field is set to the address of the next instruction to be executed as described in (RISC-V, 2022) upon debug mode entry.

When leaving debug mode, the capability in dpcc is unsealed and written into pcc. A debugger may write dpcc to change where the hart resumes and its mode, permissions, sealing or bounds.

The legalization of dpcc follows the same rules described for mepcc.

The dscratch0 register is as defined in (RISC-V, 2022). It is an optional DXLEN-bit scratch register that can be used by implementations which need it. dscratch0 is extended into dscratch0c.

The dscratch0c register is a CLEN-bit plus tag bit renamed extension to dscratch0 that is able to hold a capability.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

The dscratch1 register is as defined in (RISC-V, 2022). It is an optional DXLEN-bit scratch register that can be used by implementations which need it. dscratch1 is extended into dscratch1c.

The dscratch1c register is a CLEN-bit plus tag bit renamed extension to dscratch1 that is able to hold a capability.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

The dinfc register is a CLEN-bit plus tag bit CSR only accessible in debug mode.

The reset value is the Infinite capability.

If Zcherihybrid is implemented:

The CHERI Execution Mode Encoding of dinfc is only updated by executing MODESW.CAP or MODESW.INT from the program buffer.

The Capability Level (CL) is a new field added to the capability encoding, as shown in Section 3.1.

With LVLBITS=1, the Capability Level can hold two values: when set to 1 the capability is global (in general allowing it to be stored using any authorizing capability), and when set to 0 the capability is local, and can only be stored by authorizing capabilities with the SL-permission set. Furthermore, the EL-permission can be used to restrict loading of global capabilities — causing the hardware to automatically set the level of loaded capabilities to local instead.

As with permissions, the capability level can only be decreased but never increased (without deriving from a capability with a higher level). Therefore, the capability level is adjusted using the ACPERM instruction (see Section 6.2) and are queried using GCPERM.

Zcherilevels introduces two new capability permissions:

¹ SL isn’t applicable in these cases, but this value is reported by GCPERM to simplify the rules followed by ACPERM
² These entries are reserved when LVLBITS=1 and in use when LVLBITS=2

The effective CHERI execution mode is given by the values of some CSRs and the CHERI Execution Mode Encoding from the pcc. The following code sequences demonstrate how a program can observe the current, effective CHERI execution mode depending on the machine’s privilege mode.

In debug mode, the following sequence executed from the program buffer will write 0 for Capability Pointer Mode and 1 for Integer Pointer Mode to x1:

In any other privilege mode, the following sequence will write 0 for Capability Pointer Mode and 1 for Integer Pointer Mode to x1:

The load and store capability instructions change behavior depending on the CHERI execution mode although the instruction’s encoding remains unchanged.

The load capability instruction is LC. When the CHERI execution mode is Capability Pointer Mode; the instruction behaves as described in Section 4.3. In Integer Pointer Mode, the capability authorizing the memory access is ddc, so the effective address is obtained by adding the x register to the sign-extended offset.

The store capability instruction is SC. When the CHERI execution mode is Capability Pointer Mode; the instruction behaves as described in Section 4.3. In Integer Pointer Mode, the capability authorizing the memory access is ddc, so the effective address is obtained by adding the x register to the sign-extended offset.

A new SCMODE instruction allows setting a capability’s CHERI execution mode to the indicated value. The output is written to an unprivileged c register, not pcc.

A new GCMODE instruction allows decoding the CHERI execution mode from an arbitrary capability held in an x register. The output is written to an unprivileged x register.

New CHERI execution mode switch instructions, MODESW.CAP and MODESW.INT, allow software to change the hart’s current CHERI Execution Mode Encoding in pcc. If the current mode in the pcc is Integer Pointer Mode, then the mode after executing MODESW.CAP is Capability Pointer Mode and similarly for MODESW.INT when in Capability Pointer Mode. This instruction effectively writes the CHERI execution mode CHERI Execution Mode Encoding of the capability currently installed in the pcc.

The unconditional jump instructions change behavior depending on the CHERI execution mode although the instruction’s encoding remains unchanged.

The jump and link instruction JAL when the CHERI execution mode is Capability Pointer Mode; behaves as described in Section 4.4. When the mode is Integer Pointer Mode. In this case, the address of the instruction following the jump (pc + 4) is written to an x register; that register’s tag and capability metadata are zeroed.

The jump and link register instruction is JALR when the CHERI execution mode is Capability Pointer Mode; behaves as described in Section 4.4. When the mode is Integer Pointer Mode. In this case, the target address is obtained by adding the sign-extended 12-bit immediate to the x register operand, then setting the least significant bit of the result to zero. The target address is then written to the pcc address and a representability check is performed. The address of the instruction following the jump (pc + 4) is written to an x register; that register’s tag and capability metadata are zeroed.

Zcherihybrid allows changing the current CHERI execution mode when executing JALR from Capability Pointer Mode.

JAL and JALR cause CHERI exceptions when a minimum sized instruction at the target address is not within the bounds of the pcc. An instruction address misaligned exception is raised when the target address is misaligned.

The behavior is as shown in Section 4.4.2.2.

Load and store instructions change behavior depending on the CHERI execution mode although the instruction’s encoding remains unchanged.

Loads and stores behave as described in Section 4.4 when in Capability Pointer Mode. In Integer Pointer Mode, the instructions behave as described in the RISC-V base ISA and rely on x operands only. The capability authorizing the memory access is ddc and the memory address is given by sign-extending the 12-bit immediate offset and adding it to the base address in the x register operand.

The exception cases remain as described in Section 4.4 regardless of the CHERI execution mode.

Zcherihybrid adds the concept of CSRs which contain a capability where the address field is visible in Integer Pointer Mode (e.g. mtvec) and the full capability is visible in Capability Pointer Mode through a different name (e.g. mtvecc). These are referred to as extended CSRs. Also, Zcherihybrid adds the new capability CSRs listed in Table 32.

Extended CSRs have only one address; the access width is determined by the execution mode.

When CSRRW is executed on an extended CSR in Integer Pointer Mode:

When CSRRW is executed on an extended CSR in Capability Pointer Mode, or on a new capability CSR regardless of the CHERI execution mode:

When an extended CSR or a new capability CSR is used with another CSR instruction (CSRRWI, CSRRC, CSRRCI, CSRRS, CSRRSI):

All CSR instructions cause CHERI exceptions if the pcc does not grant ASR-permission and the CSR accessed is not user-mode accessible.

Zcherihybrid eliminates some restrictions for SXL and UXL imposed in Zcheripurecap to allow implementations supporting multiple base ISAs. Namely, the SXL and UXL fields may be writable.

Setting the SXL or UXL field to a value that is not MXLEN disables most CHERI features and instructions, as described in Section 7.7, while in that privilege mode.

Whenever XLEN in any mode is set to a value less than MXLEN, standard RISC-V rules from (RISC-V, 2023) are followed. This means that all operations must ignore source operand register bits above the configured XLEN, and must sign-extend results to fill all MXLEN bits in the destination register. Similarly, pc bits above XLEN are ignored, and when the pc is written, it is sign-extended to fill MXLEN. The integer writing rule from CHERI is followed, so that every register write also zeroes the metadata and tag of the destination register.

However, CHERI operations and security checks will continue using the entire hardware register (i.e. CLEN bits) to correctly decode capability bounds.

Zcherihybrid eliminates some restrictions for MBE, SBE, and UBE imposed in Zcheripurecap to allow implementations supporting multiple endiannesses. Namely, the MBE, SBE, and UBE fields may be writable if the corresponding privilege mode is implemented.

Setting the MBE, SBE, or UBE field to a value that is not the reset value of MBE disables most CHERI features and instructions, as described in Section 7.7, while in that privilege mode.

The mtdc register is a capability width read/write register dedicated for use by machine mode. Typically, it is used to hold a data capability to a machine-mode hart-local context space, to load into ddc.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

Access to this CSR is illegal if CHERI register and instruction access is disabled for the current privilege.

Zcherihybrid adds a new enable bit to mseccfg as shown in Figure 38.

The CHERI Register Enable (CRE) bit controls whether M-mode and lower privilege levels have access to capability registers and instructions. When mseccfg.CRE=1, all CHERI instructions and registers can be accessed. When mseccfg.CRE=0, CHERI register and instruction access is prohibited for M-mode and lower privilege levels as described in Section 7.7.

The reset value is 0.

Zcherihybrid adds a new enable bit to menvcfg as shown in Figure 39.

The CHERI Register Enable (CRE) bit controls whether less privileged levels can perform explicit accesses to CHERI registers and execute CHERI instructions. When menvcfg.CRE=1 and mseccfg.CRE=1, CHERI registers can be read and written by less privileged levels. When menvcfg.CRE=0, CHERI registers are disabled in less privileged levels as described in Section 7.7.

The reset value is 0.

The stdc register is a capability width read/write register dedicated for use by supervisor mode. Typically, it is used to hold a data capability to a supervisor-mode hart-local context space, to load into ddc.

The tag of the CSR must be reset to zero. The reset values of the metadata and address fields are UNSPECIFIED.

Access to this CSR is illegal if CHERI register and instruction access is disabled for the current privilege.

The senvcfg register operates as described in the RISC-V Privileged Specification. Zcherihybrid adds a new enable bit as shown in Figure 41.

The CHERI Register Enable (CRE) bit controls whether U-mode can perform explicit accesses to CHERI registers and execute CHERI instructions. When senvcfg.CRE=1 and menvcfg.CRE=1 and mseccfg.CRE=1 CHERI registers can be read and written by U-mode. When senvcfg.CRE=0, CHERI registers are disabled in U-mode as described in Section 7.7.

The reset value is 0.

The ddc CSR is a read-write capability register implicitly used as an operand to authorize all data memory accesses when the current CHERI mode is Integer Pointer Mode. This register must be readable in any implementation. Its reset value is the Infinite capability.

Access to this CSR is illegal if CHERI register and instruction access is disabled for the current privilege.

As shown in Table 51, ddc is a data pointer, so it does not need to be able to hold all possible invalid addresses.

The mtid register is an MXLEN-bit read-write register. It is used to identify the current software thread in machine mode. The reset value of this register is UNSPECIFIED.

The stid register is an SXLEN-bit read-write register. It is used to identify the current software thread in supervisor mode. The reset value of this register is UNSPECIFIED.

The vstid register is a VSLEN-bit read-write register. It is VS-mode’s version of supervisor register stid used to identify the current software thread in virtual supervisor mode. As other Virtual Supervisor registers when V=1, vstid substitutes for stid, so that instructions that normally read or modify stid actually access vstid instead. When V=0, vstid does not directly affect the behavior of the machine.

The reset value of this register is UNSPECIFIED.

The utid register is an UXLEN-bit read-write register. It is used to identify the current software thread in user mode. The reset value of this register is UNSPECIFIED.

When Zcheripurecap is implemented, the Zstid CSRs are extended as follows:

The mtidc register is an CLEN-bit read-write capability register. It is the capability extension of the mtid register. It is used to identify the current software thread in machine mode. On reset the tag of mtidc will be set to 0 and the remainder of the data is UNSPECIFIED.

The stidc register is an CLEN-bit read-write capability register. It is the capability extension of the stid register. It is used to identify the current software thread in supervisor mode. On reset the tag of stidc will be set to 0 and the remainder of the data is UNSPECIFIED.

The vstidc register is a CLEN-bit read-write capability register. It is the capability extension of the vstid register used to identify the current software thread in virtual supervisor mode. As other Virtual Supervisor registers when V=1, vstidc substitutes for stidc, so that instructions that normally read or modify stidc actually access vstidc instead. When V=0, vstidc does not directly affect the behavior of the machine. On reset the tag of vstidc will be set to 0 and the remainder of the data is UNSPECIFIED.

The utidc register is an CLEN-bit read-write capability register. It is the capability extension of the utid register. It is used to identify the current software thread in user mode. On reset the tag of utidc will be set to 0 and the remainder of the data is UNSPECIFIED.

See MODESW.CAP.