RISC-V Cache-Block Operations: Diagnose Privilege Gating Before Assuming Zicbom Is Missing

A cbo.clean instruction assembles successfully and works in machine firmware, but the same operation traps in supervisor software. That does not by itself show that the processor lacks Zicbom. Higher-privilege environment controls can deliberately prohibit the instruction below M-mode.

Diagnose instruction availability, privilege permission and address access as separate questions. The following discussion uses non-virtualized M/S/U execution; virtual-machine controls introduce additional exception paths.

Identify the operation and its controlling field

The pinned cache-block operation specification assigns cbo.clean, cbo.flush and cbo.inval to Zicbom. Zeroing and prefetch operations belong to different extensions, so support for one class does not establish support for every CBO instruction.

For clean and flush below M-mode, menvcfg.CBCFE must permit execution. U-mode also depends on the supervisor control where applicable. A lower privilege cannot override a higher-level prohibition merely by setting its own environment field.

The Machine-Level ISA environment configuration specifies that absent Zicbom makes the corresponding fields read-only zero. But observing zero in a field alone does not distinguish absent hardware from an implemented feature that firmware has left disabled. Use the execution environment's advertised capabilities and installed policy together.

Invalidate permission also selects semantics

CBIE is more than a boolean enable. In the examined specification, 00 prohibits lower-mode invalidate, 01 makes the instruction perform a flush, and 11 permits invalidate unless another applicable lower-level control requests flush. Encoding 10 is reserved.

For example, supervisor code executing cbo.inval under menvcfg.CBIE=01 performs a flush operation. It must not describe the operation as discarding dirty data without writeback merely because the assembly mnemonic says invalidate.

This redirection has a security purpose described by the specification: invalidating a modified block before its changes reach memory can expose stale data. Higher-privilege software can require flushing or trap the operation rather than allowing unrestricted invalidate semantics.

Do not change these controls just to make an application stop trapping. They form part of the firmware and operating-system policy, and legal settings should come from the supported discovery mechanism.

A permitted instruction can still fail on its address

Cache-block management instructions use an effective address and are subject to translation and physical protection. The specification permits them when a load or store is permitted to the corresponding physical addresses. If neither is permitted, translation rejection produces a store-class page fault, while other access rejection produces a store access fault in the non-virtualized case.

This classification follows the cited CMO chapter. The same fixed source snapshot has an inconsistency: the Machine-Level PMP overview still lists cache-block management instructions under load access faults. Check the target implementation and applicable errata rather than assuming those two passages agree. This differs from the illegal-instruction exception caused by a disabled environment gate. Preserve the trap cause and address information before deciding which layer to investigate. An execute-only mapping is not a portable loophole: behavior when only instruction fetch is permitted is specified as unspecified for these management operations.

The operation also covers a cache block rather than an arbitrary byte-length buffer. Discover the management block size and ensure that the applicable PMP permissions and physical memory attributes satisfy the specification's block-wide consistency constraints. A valid pointer to one byte is insufficient evidence for the whole block.

Use a diagnostic with distinguishable outcomes

A proposed controlled check first confirms the actual instruction encoding and advertised Zicbom support, then records execution mode and applicable environment fields. If those permit execution, use an approved ordinary-memory block with known translation and protection policy before investigating a special mapping.

Classify the result as unavailable instruction, privilege-gate rejection, redirected invalidate semantics or address-access failure. Keep cache visibility and device ownership analysis separate: successfully executing a CBO instruction does not prove a complete DMA synchronization protocol. No cache operation, CSR write or target test was executed for this article.