{cheri_default_ext_name} is an optional extension to {cheri_base_ext_name}. Implementations that support {cheri_base_ext_name} and {cheri_default_ext_name} define a variant of the CHERI ISA that is fully binary compatible with existing RISC-V code.
Key features in {cheri_default_ext_name} include a definition of a CHERI execution mode, a new unprivileged register, additional instructions and extensions to some existing CSRs enabling CHERI features. The remainder of this section describes these features in detail as well as their integration with the primary base integer variants of the RISC-V ISA (RV32I and RV64I).
{cheri_default_ext_name} adds CHERI execution modes to ensure backwards compatibility with the base RISC-V ISA while saving instruction encoding space. There are two execution modes: {cheri_cap_mode_name} and {cheri_int_mode_name}. Additionally, there is a new unprivileged register: the default data capability, ddc, that is used to authorize all data memory accesses when in {cheri_int_mode_name}.
The current CHERI execution mode is given by the CHERI Execution Mode Encoding field of [pcc] that is encoded as described in CHERI Execution Mode Encoding.
The CHERI execution mode impacts the instruction set in the following ways:
-
The authorizing capability used to execute memory access instructions. In {cheri_int_mode_name}, ddc is implicitly used. In {cheri_cap_mode_name}, the authorizing capability is supplied as an explicit c operand register to the instruction.
-
The set of instructions that is available for execution. Some instructions are available in {cheri_int_mode_name} but not {cheri_cap_mode_name} and vice-versa (see [riscv-extensions]).
|
Note
|
The implication is that the CHERI execution mode is always {cheri_cap_mode_name} on implementations that support {cheri_base_ext_name}, but not {cheri_default_ext_name}. |
The CHERI execution mode is effectively an extension to some RISC-V instruction
encodings. For example, the encoding of an instruction like [LW] remains
unchanged, but the mode indicates whether the capability authorizing the load
is the register operand cs1 ({cheri_cap_mode_name}). The mode is shown in the assembly
syntax.
The CHERI execution mode is key in providing backwards compatibility with the base RISC-V ISA. RISC-V software is able to execute unchanged in implementations supporting both {cheri_base_ext_name} and {cheri_default_ext_name} provided that the [infinite-cap] capability is installed in ddc and [pcc] (with M={INT_MODE_VALUE}, i.e. in {cheri_int_mode_name}). Setting both registers to [infinite-cap] ensures that:
-
All permissions are granted
-
The bounds authorize accesses to the entire address space i.e base is 0 and top is 2MXLEN
{cheri_default_ext_name} adds a new CHERI execution Mode field (M) to the capability format, which is only valid for code capabilities, i.e. when the [x_perm] is set.
-
When MXLEN=32, the Mode is encoded in bit 0 of quadrant 1 from the AP field even though it is not a permission as shown in [cap_perms_encoding32].
-
Only quadrant 1 represents executable capabilities, and so it’s the only one which encodes the Mode.
-
-
When MXLEN=64, the Mode is encoded separately; a new CHERI Execution Mode Encoding field is added to the capability format as shown in [cap_perms_encoding64]. The CHERI Execution Mode Encoding is only valid for code capabilities, otherwise the field is reserved.
|
Note
|
Mode is encoded with permissions for MXLEN=32, but is not a permission. It is orthogonal to permissions as it can vary arbitrarily using [SCMODE]. |
In both encodings:
-
Mode (M)={CAP_MODE_VALUE} indicates {cheri_cap_mode_name}.
-
Mode (M)={INT_MODE_VALUE} indicates {cheri_int_mode_name}.
The current CHERI execution mode is given by the CHERI Execution Mode Encoding of the [pcc] and the CHERI register and instruction access settings as follows:
-
The Mode is {cheri_cap_mode_name} when the CHERI Execution Mode Encoding of the [pcc] is {CAP_MODE_VALUE}, and CHERI register and instruction access is enabled for the current privilege.
-
Otherwise the Mode is {cheri_int_mode_name}.
When the CHERI Execution Mode Encoding can be set, the rules defined by [ACPERM] must be followed.
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 {CAP_MODE_VALUE} for {cheri_cap_mode_name} and
{INT_MODE_VALUE} for {cheri_int_mode_name} to x1:
csrr c1, dinfc
gcmode x1, c1In any other privilege mode, the following sequence will write {CAP_MODE_VALUE}
for {cheri_cap_mode_name} and {INT_MODE_VALUE} for
{cheri_int_mode_name} to x1:
auipc c1, 0
gctag x1, c1{cheri_default_ext_name} introduces a small number of new mode-switching and capability manipulation instructions to the base RISC-V integer ISA, as shown in [Zcheri_hybrid_instruction_extension]. Additionally, the behavior of some existing instructions changes depending on the current CHERI execution mode.
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 {cheri_cap_mode_name}; the instruction behaves as described in [section_cap_instructions]. In {cheri_int_mode_name}, 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 {cheri_cap_mode_name}; the instruction behaves as described in [section_cap_instructions]. In {cheri_int_mode_name}, 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 {cheri_int_mode_name}, then the mode after executing [MODESW_CAP] is {cheri_cap_mode_name} and similarly for [MODESW_INT] when in {cheri_cap_mode_name}. This instruction effectively writes the CHERI execution mode CHERI Execution Mode Encoding of the capability currently installed in the [pcc].
The CHERI execution mode introduced in {cheri_default_ext_name} affects the behavior of instructions that have at least one memory address operand. When in {cheri_cap_mode_name}, the address input or output operands may include c registers. When in {cheri_int_mode_name}, the address input or output operands are x/f/v registers; the tag and metadata of that register are implicitly set to 0.
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 {cheri_cap_mode_name}; behaves as described in [section_existing_riscv_insns]. When the mode is {cheri_int_mode_name}. 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 {cheri_cap_mode_name}; behaves as described in [section_existing_riscv_insns]. When the mode is {cheri_int_mode_name}. 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.
{cheri_default_ext_name} allows changing the current CHERI execution mode when executing [JALR] from {cheri_cap_mode_name}.
The behavior is as shown in [condbr-purecap].
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_existing_riscv_insns] when in {cheri_cap_mode_name}. In {cheri_int_mode_name}, 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_existing_riscv_insns] regardless of the CHERI execution mode.
{cheri_default_ext_name} adds the concept of CSRs which contain a capability where the address field is visible in {cheri_int_mode_name} (e.g. [mtvec]) and the full capability is visible in {cheri_cap_mode_name} through a different name (e.g. [mtvecc]). These are referred to as extended CSRs. Also, {cheri_default_ext_name} adds the new capability CSRs listed in Table 1.
Extended CSRs have only one address; the access width is determined by the execution mode.
When [CSRRW] is executed on an extended CSR in {cheri_int_mode_name}:
-
The register operand is an x register.
-
Only XLEN bits from the x source are written to the capability address field.
-
The tag and metadata are updated as specified in [extended_CSR_writing].
-
-
Only XLEN bits are read from the capability address field, which are extended to MXLEN bits according to cite:[riscv-priv-spec] (3.1.6.2. Base ISA Control in mstatus Register) and are then written to the destination x register.
When [CSRRW] is executed on an extended CSR in {cheri_cap_mode_name}, or on a new capability CSR regardless of the CHERI execution mode:
-
The register operand is a c register.
-
The full capability in the c register source is written to the CSR.
-
The capability may require modification before the final written value is determined (see [extended_CSR_writing]).
-
-
The full capability is written to destination c register.
When an extended CSR or a new capability CSR is used with another CSR instruction ([CSRRWI], [CSRRC], [CSRRCI], [CSRRS], [CSRRSI]):
-
The final address is calculated according to the standard RISC-V CSR rules (set bits, clear bits etc).
-
The final address is updated as specified in [extended_CSR_writing] for an XLEN write.
-
When accessing an extended CSR:
-
In {cheri_int_mode_name}, XLEN bits are read from the capability address field and written to an output x register.
-
In {cheri_cap_mode_name}, CLEN bits are read from the CSR and written to an output c register.
-
-
When accessing a new capability CSR:
-
CLEN bits are read from the CSR and written to an output c register.
-
All CSR instructions cause CHERI exceptions if the [pcc] does not grant [asr_perm] and the CSR accessed is not user-mode accessible.
{cheri_default_ext_name} allows [MODESW_CAP] and [MODESW_INT] to execute in debug mode.
When entering debug mode, whether the core enters {cheri_int_mode_name} or {cheri_cap_mode_name} is controlled by the CHERI Execution Mode Encoding in [dinfc].
The current mode can be read from [dinfc].
{TAG_RESET_CSR}
{REQUIRE_HYBRID_CSR}
Upon entry to debug mode, ddc is saved in dddc. ddc's metadata is set to the [infinite-cap] capability’s metadata (with tag set) and ddc's address remains unchanged.
When debug mode is exited by executing [DRET], the hart’s ddc is updated to the capability stored in dddc. A debugger may write dddc to change the hart’s context.
As shown in [CSR_exevectors], dddc is a data pointer, so it does not need to be able to hold all possible invalid addresses.
{cheri_default_ext_name} includes functions to disable explicit access to CHERI registers and instructions. The following occurs when executing code in a privilege mode that has CHERI register access disabled:
-
The CHERI instructions in [section_cap_instructions] and [instruction-modes] cause illegal instruction exceptions
-
Executing CSR instructions accessing any CSR added by {cheri_default_ext_name} (see CLEN-wide CSRs added in {cheri_default_ext_name}) causes an illegal instruction exception
-
Executing CSR instructions accessing any extended CSR (see [csr-numbers-section]) only allows XLEN access.
-
All allowed instructions execute as if the CHERI execution mode is {cheri_int_mode_name}. The mode bit in [pcc] is treated as if it was zero while CHERI register access is disabled.
CHERI register access is disabled if
-
XLEN in the current mode is less than MXLEN, or
-
the endianness in the current mode is not the reset value of [mstatus].MBE, or
-
the effective CRE for the current privilege is 0.
The effective CRE for the current privilege is:
-
Machine:
mseccfg.CRE -
Supervisor:
mseccfg.CRE & menvcfg.CRE -
User:
mseccfg.CRE & menvcfg.CRE & senvcfg.CRE
|
Note
|
The effective CRE is always 1 in debug mode. |
Disabling CHERI register access has no effect on implicit accesses or security checks. The last capability installed in [pcc] and ddc before disabling CHERI register access will be used to authorize instruction execution and data memory accesses.
|
Note
|
Disabling CHERI register access prevents low-privileged {cheri_int_mode_name} software from interfering with the correct operation of higher-privileged {cheri_int_mode_name} software that do not perform ddc switches on trap entry and return. Disable CHERI register access also allows harts supporting CHERI to be fully compatible with standard RISC-V, so CHERI instructions, such as [CRAM], that do not change the state of CHERI CSRs raise exceptions when CRE=0. |
|
Note
|
[cheri_behavior_cre_mode] summarizes the behavior of a hart in connection with the CRE and the CHERI execution mode. |
{cheri_default_ext_name} adds the CLEN-wide CSRs shown in Table 1.
{cheri_default_ext_name} eliminates some restrictions for SXL and UXL imposed in {cheri_base_ext_name} 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 Disabling CHERI Registers and Instructions, while in that privilege mode.
|
Note
|
If CHERI register access must be disabled in a mode for security reasons, software should set CRE to 0 regardless of the SXL and UXL fields. |
Whenever XLEN in any mode is set to a value less than MXLEN, standard RISC-V rules from cite:[riscv-unpriv-spec] 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.
{cheri_default_ext_name} eliminates some restrictions for MBE, SBE, and UBE imposed in {cheri_base_ext_name} 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 Disabling CHERI Registers and Instructions, 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.
{TAG_RESET_CSR}
{REQUIRE_CRE_CSR}
{REQUIRE_HYBRID_CSR}
{cheri_default_ext_name} adds a new enable bit to mseccfg as shown in Machine security configuration register (mseccfg).
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 Disabling CHERI Registers and Instructions.
The reset value is 0.
{cheri_default_ext_name} adds a new enable bit to menvcfg as shown in Machine environment configuration register (menvcfg).
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 Disabling CHERI Registers and Instructions.
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.
{TAG_RESET_CSR}
{REQUIRE_CRE_CSR}
{REQUIRE_HYBRID_CSR}
The senvcfg register operates as described in the RISC-V Privileged Specification. {cheri_default_ext_name} adds a new enable bit as shown in Supervisor environment configuration register (senvcfg).
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 Disabling CHERI Registers and Instructions.
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 {cheri_int_mode_name}. This register must be readable in any implementation. Its reset value is the [infinite-cap] capability.
{REQUIRE_CRE_CSR}
|
Note
|
CRE is not required for the implicit access required by checking memory accesses against ddc |
{REQUIRE_HYBRID_CSR}
As shown in [CSR_exevectors], ddc is a data pointer, so it does not need to be able to hold all possible invalid addresses.