Int2ptr and runtime provenance models

[InfernoDeity]

@comex

For example, breaking a pointer into individual bytes and then reconstituting it is something that compile-time provenance models typically want to allow, in order to support naive implementations of memcpy . But under CHERI this is in general impossible. (If those bytes stay in registers, then it can work, because at least in Morello, both the lower and upper bounds of a capability are tracked separately from the value itself. But if the user sticks the byte in memory somewhere, then there's nowhere to put the bounds.)

Wouldn't this be solved by the provenance being adjacent in memory to the pointer, or even stored as part of the bytes of the pointer? Stepping away from CHERI in specific, and towards, say, miri's model, copying the bytes of a pointer copies the pointer, because the provenance is encoded directly in the bytes. And using a model involving 2 hardware-level pointers, one to the data, one to the provenance would work if they were adjacent in memory and both part of the pointer data.

@comex

unless we change usize to 128-bit, but that would have its own problems.

Oh hey, [Pre-RFC] usize is not size_t.