CHERIoT: MEPCC Initialization Issue In TestRIG

Introduction

This article delves into a critical discrepancy concerning the initialization of the MEPCC (Machine Exception Program Counter Capability) and MEPC (Machine Exception Program Counter) registers within the CHERIoT platform, specifically when interacting with the TestRIG environment. Understanding this issue is crucial for developers and testers working with CHERIoT, as it directly impacts the behavior of exception handling and overall system stability. The core problem stems from differing initialization approaches between the CHERIoT hardware design and the SAIL (Specification Architecture Intermediate Language) model, leading to potential inconsistencies during verification and testing. In essence, the hardware initializes these registers with specific values tailored for its execution environment, while the SAIL model might not accurately reflect these initial states. This mismatch can cause unexpected behavior, especially when running tests that rely on precise exception handling. Therefore, resolving this initialization issue is essential for ensuring the reliability and predictability of the CHERIoT platform.

The Discrepancy: MEPCC and MEPC Initialization

The heart of the matter lies in how CHERIoT initializes its MEPCC SCR (Special Control Register). According to the CHERIoT-Ibex repository, the MEPCC is initialized with "infinite" bounds and a base address of zero. This initialization can be found in the cheri_pkg.sv file within the repository. Specifically, the relevant line of code sets the MEPCC to have a capability that effectively allows it to access any memory location. This approach makes sense in the context of a bare-metal system where the initial exception handler might need to be located anywhere in memory. However, when CHERIoT is run under the RVFI (RISC-V Formal Interface), the MEPC CSR (Control and Status Register) address is forced to 0x80000000 by the TestRIG. This address is a specific, fixed location in memory, typically where the operating system kernel or a similar high-privilege component resides. The TestRIG's behavior is intended to simulate a more realistic environment where the exception handler is located at a well-defined address.

On the other hand, the SAIL model of CHERIoT does not perform any such initialization. Unlike the hardware design and the TestRIG environment, the SAIL model does not explicitly set the MEPCC or MEPC to specific values at the start of execution. This omission creates a potential divergence between the simulated behavior and the actual hardware behavior. When the SAIL model is used for verification or testing, it might not accurately reflect the initial state of the exception handling mechanism in the real hardware. This can lead to false positives or false negatives in tests, making it difficult to ensure the correctness of the CHERIoT design. The lack of initialization in the SAIL model is a critical issue that needs to be addressed to improve the accuracy and reliability of CHERIoT verification.

Potential Solutions and Considerations

One proposed solution, mirroring the approach taken in a related issue, involves modifying the SAIL model to explicitly initialize the MEPCC. Specifically, the suggestion is to add the line MEPCC = { root_cap_exe with address = 0x80000000 }; to the cheri_regs.sail file. This line would set the MEPCC to a capability derived from the root capability for executable code, but with its address explicitly set to 0x80000000. This would align the SAIL model's initial state with the TestRIG's behavior, ensuring that both environments start with the MEPC pointing to the same address. However, the author notes that issue #116 might complicate this approach, indicating a potential conflict or dependency that needs to be resolved first.

It's essential to consider the implications of any changes to the initialization process. The initial values of MEPCC and MEPC are crucial for the correct functioning of the exception handling mechanism. If these registers are not initialized correctly, the system might crash or behave unpredictably when an exception occurs. Therefore, any modifications to the initialization process must be carefully tested and verified to ensure that they do not introduce new issues.

Furthermore, the choice of 0x80000000 as the initial MEPC value should be carefully considered. This address is typically reserved for the operating system kernel or other high-privilege code. If the system is not designed to start execution at this address, setting the MEPC to this value might cause problems. It's essential to ensure that the initial MEPC value is compatible with the system's overall memory map and boot process.

Implications for Testing and Verification

The discrepancy in MEPCC and MEPC initialization has significant implications for testing and verification of the CHERIoT platform. If the SAIL model and the TestRIG environment have different initial states, tests run in these environments might produce inconsistent results. This can make it difficult to determine whether a bug is in the hardware design, the SAIL model, or the test itself.

For example, a test that relies on a specific exception handler being located at address 0x80000000 might pass in the TestRIG environment but fail in the SAIL model, or vice versa. This inconsistency can lead to wasted time and effort in debugging and resolving the issue. To address this problem, it's essential to ensure that the SAIL model and the TestRIG environment have consistent initial states. This can be achieved by modifying the SAIL model to explicitly initialize the MEPCC and MEPC registers to the same values as the TestRIG environment.

Furthermore, it's important to develop tests that are robust to variations in the initial state of the MEPCC and MEPC registers. These tests should check that the exception handling mechanism works correctly regardless of the initial values of these registers. This can be achieved by writing tests that explicitly set the MEPCC and MEPC registers to different values and then trigger an exception to verify that the correct exception handler is invoked.

Conclusion

The issue of differing MEPCC and MEPC initialization between CHERIoT's hardware and its SAIL model presents a significant challenge for ensuring the platform's reliability and predictability. The current discrepancy can lead to inconsistencies in testing and verification, potentially masking underlying bugs or creating false positives. Addressing this issue requires a careful and coordinated approach, involving modifications to the SAIL model to align its initial state with the hardware and TestRIG environment. Additionally, developing robust tests that are resilient to variations in initial register states is crucial for comprehensive verification.

By resolving this initialization issue, the CHERIoT platform can achieve a higher level of confidence in its correctness and robustness, paving the way for more reliable and secure embedded systems. Further investigation into the dependencies and potential conflicts, as highlighted by issue #116, is also necessary to ensure a smooth and effective solution.

For more information on capability-based security, you can visit the CHERI website.