You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand we designed MPI_GET_ADDRESS and related concepts around segmented addressing, where an address is bigger than a pointer. Thus, we created a way to turn pointers into addresses, and have a thing called an address integer.
While segmented addressing is no longer relevant anywhere I can see, except the C standard, we now see platforms where pointers are bigger than addresses. For example, https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf. In this platform, which has silicon implementations, pointers are larger than addresses (often 128b versus 64b).
More importantly, on the CHERI platform, addresses cannot be converted to dereferenceable pointers without the use of an existing valid pointer [1]. As such, if one were to use MPI_GET_ADDRESS as prescribed and create a datatype based absolute addressing and pass MPI_BOTTOM as the buffer, the MPI implementation cannot use the buffer associated with that datatype without manually defeating the memory safety mechanisms built into the platform.
[1] "vaddr_t This is a new integer type introduced by CHERI C and should be used to hold virtual addresses. vaddr_t should not be directly cast to a pointer type for dereference; instead, it must be combined with an existing valid capability to the address space to generate a dereferenceable pointer.Typically, this is done using the cheri_address_set(c, x) function." (From the link)
Proposal
We must explicitly say that MPI_Aint is large enough to hold a pointer. On the CHERI platform, intptr_t is the only integer kind that can be used to store a pointer. Unfortunately, there are apparently two platforms where intptr_t is not supported (due to intmax_t ABI compatibility problems) so we cannot strictly assume it, although we can say that MPI_Aint must be equivalent to its definition in C.
Changes to the Text
TODO
Impact on Implementations
This is not an issue on most platforms, but is solved by ensuring that MPI_Aint is equivalent to intptr_t.
Impact on Users
This is necessary to ensure MPI will work on platforms with fat pointers.
References and Pull Requests
The text was updated successfully, but these errors were encountered:
jeffhammond
changed the title
MPI_Aint needs to be wide enough to hold a pointers, not just an address
MPI_Aint needs to be wide enough to hold a pointer, not just an address
May 3, 2023
Problem
I understand we designed
MPI_GET_ADDRESS
and related concepts around segmented addressing, where an address is bigger than a pointer. Thus, we created a way to turn pointers into addresses, and have a thing called an address integer.While segmented addressing is no longer relevant anywhere I can see, except the C standard, we now see platforms where pointers are bigger than addresses. For example, https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf. In this platform, which has silicon implementations, pointers are larger than addresses (often 128b versus 64b).
More importantly, on the CHERI platform, addresses cannot be converted to dereferenceable pointers without the use of an existing valid pointer [1]. As such, if one were to use
MPI_GET_ADDRESS
as prescribed and create a datatype based absolute addressing and passMPI_BOTTOM
as the buffer, the MPI implementation cannot use the buffer associated with that datatype without manually defeating the memory safety mechanisms built into the platform.[1] "vaddr_t This is a new integer type introduced by CHERI C and should be used to hold virtual addresses. vaddr_t should not be directly cast to a pointer type for dereference; instead, it must be combined with an existing valid capability to the address space to generate a dereferenceable pointer.Typically, this is done using the cheri_address_set(c, x) function." (From the link)
Proposal
We must explicitly say that
MPI_Aint
is large enough to hold a pointer. On the CHERI platform,intptr_t
is the only integer kind that can be used to store a pointer. Unfortunately, there are apparently two platforms whereintptr_t
is not supported (due tointmax_t
ABI compatibility problems) so we cannot strictly assume it, although we can say thatMPI_Aint
must be equivalent to its definition in C.Changes to the Text
TODO
Impact on Implementations
This is not an issue on most platforms, but is solved by ensuring that
MPI_Aint
is equivalent tointptr_t
.Impact on Users
This is necessary to ensure MPI will work on platforms with fat pointers.
References and Pull Requests
The text was updated successfully, but these errors were encountered: