Lack of pointer/memory versioning

[jonwoodruff]

Memory/pointer versioning (a la SPARC ADI, ARM MTE) is likely to coexist with CHERI in commercial implementations, which has the potential of drastically affecting the way that CHERI capabilities are used.
We are currently unable to evaluate CHERI in the presence of memory versioning with the current implementation.

Section D.9 of the Cheri Architecture document v7 proposes a concrete and practical implementation of memory-versioning for CHERI-RISC-V. This has 4 instructions for getting and setting version numbers on pointers and memory words respectively. Strictly speaking, we may only need the instructions for setting version numbers.

I see 4 packages of work in implementing memory-versioning in Toooba:
1. Extend tags to hold versions.
This is most easily done if the versioning granule is equal to the capability size such that the tag field for capabilities can simply be enlarged. The TagController itself can be configured to expect 32-bit capabilities, for example, and therefore deliver 4-bits per capability word. Thus the memory hierarchy will preserve 3 additional bits for each 16-byte word that can be used as a version.
2. Add SetVersion instruction.
This instruction should follow the pattern of SetFlag in the implementation, and will need a new field in the capability. If bits are borrowed from the pointer field, the Cap type class should be able to hide this fairly well from the implementation. That is, the CapReg and CapPipe formats would have a dedicated Version field and a 64-bit address. When CapMem is cast into either format, the upper bits would be zeroed and the version copied into the dedicated field. The rest of the functions which operate on CapReg or CapPipe would be unchanged. We may need a special GetAddr for CapMem which ignores the top bits.
3. Add StoreVersion instruction.
This instruction might follow the pattern of atomic stores, though we don't need a return value to the pipeline. Specifically, we'll need to pass a new memory operation type into the caches and potentially all the way to the TagController. I believe the atomics have a whole encoding space for communicating special memory operations which might be used.
4. Implement version checks.
I'm a bit unclear on what the best approach is here, though an initial implementation might use the existing atomic machinery to implement all stores. E.g., following the pattern of SC which sends a store value into the memory subsystem and returns back success or failure. In this case it would send the store with the version which may fail if the version does not match and return the failure to the pipeline to cause an exception. Thankfully Toooba appears to be able to throw exceptions based on errors returned from the memory subsystem (at least on MMIO in my experience).

[rwatson]

NB: This feature, if present, will require some moderately complex OS platform changes to support setting/maintaining memory version tags on pages, both in the kernel and in user allocators. It may make sense to review the MTE-related changes developed by Arm to the Linux kernel for this feature to understand the potential scope of those changes.

[nwf]

Note that the forthcoming ISAv8 makes some changes to the sketch in the appendix, notably adding an atomic instruction that mutates tags and specifying interaction with DDC so that we can, in principle, run integer-pointer MTE experiments as well.