new type: ptraddr_t

[brooks]

Summary

ptraddr_t is an unsigned integer type that can hold the address of any
pointer. It differes from uintptr_t in that it does not carry
provenance which is useful for CHERI in that it can disambigurate the
provenance of uintptr_t expressions. It differes from size_t in that
some segmented architecture (not supported by FreeBSD) may have a size_t
that does not hold an address.

ptraddr_t is not yet standardized, but is currently proposed for
inclusion in C++2Y.

Prefer the compiler defined PTRADDR_TYPE defintion where available
as this a new type and we don't need to worry about historical values.
Fall back to __size_t where unavailable.

Effort: CHERI upstreaming
Sponsored by: Innovate UK

[kib]

So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

[brooks]

In D53817#1229542, @kib wrote:

So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

I don't find that option very palatable. I suppose we could use __ptraddr_t everywhere, but then we'd face considerable churn later (CheriBSD has over 500 lines containing ptraddr_t.)

The only question the first committee to review it had was: what type should subtraction produce so I don't anticipate semantic change (and any should happen well before 16.0).

[markj]

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

[brooks]

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

[markj]

In D53817#1229564, @brooks wrote:

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

Right now vm_offset_t is inconsistent and sometimes equivalent to a ptraddr_t and sometimes to a uintptr_t. In CheriBSD we've converted a significant number of vm_offset_t's to a new vm_pointer_t because we need provenance preservation. I think @jhb wants to convert many of those into void *, but I'm a little unclear on the overalls scope. @alfredo.mazzinghi_cl.cam.ac.uk thinks we do end up with vm_pointer_t at least for a while as too much math is done on those for using void * to be comfortable.

Should we just use uintptr_t instead of vm_pointer_t? That is, do we have vm_pointer_t just to keep consistency in the Mach VM code? (That's fine if so, I just want to make sure I understand.)

D53818 actually does redefine vm_offset_t to ptraddr_t which isn't quite right, but will be once I extract the vm_pointer_t patches.

There's a bigger long term question if vm_foo_t should exist at all. I don't have a strong opinion there.

Me neither, but it's a lot of churn to remove at least vm_offset_t. vm_paddr_t and vm_pindex_t have no obvious substitute. vm_ooffset_t would have to be uint64ptr_t I think.