Tag clearing vs trapping for store capability violations: resolve TODO?

[rmn30]

https://riscv.github.io/riscv-cheri/#_capability_load_and_store_instructions currently contains a TODO saying that storing a tagged capability via a capability that does not have the C permission may cause a trap in future rather than clearing the tag of the stored capability as it does at the moment.

This is a point of divergence for CHERIoT which currently traps in this case (but not in the case of a store-local / capability level violation). Trapping may be slightly preferable for software as it detects the error sooner, but is more difficult for hardware as it introduces a data dependent trap.

[davidchisnall]

I would not want the standard to mandate trapping in the core specification because (as we learned with Morello), the data-dependent trap in the store can be painful on superscalar implementations. At the same time, it's fairly easy to implement on in-order pipelines.

From a software perspective, the trap is useful. We can avoid traps in memcpy and other forms of type-oblivious copy by propagating the MC permission from the destination to the source (if the destination lacks store-capability, remove load-capability from the source). This lets you avoid taking traps when copying untrusted data, but otherwise storing a capability via a !MC capability is silent data corruption in the tag-clearing case and so catching it early is beneficial.

Prior to ratifying the standard, it would be nice to ensure that both forms are supported. On big systems, the trapping mode may be useful as a per-process debugging feature for things willing to take the performance hit (and as a store barrier for concurrent garbage collection), but the tag-clearing option is a better default. A *NIX profile should at least provide a tag-clearing mode, and optionally a trapping mode. An embedded profile should be free to use only the trapping mode.