On Fri, Oct 21, 2022 at 02:34:48PM +0200, Kevin Brodsky wrote:
On 18/10/2022 22:16, Beata Michalska wrote:
Minor: How about make_user_ptr_with_capability()? privileged may confuse with privilege mode or something else. Although I don't have strong opinion here.
I agree, "privileged" is a very overloaded term. What I am trying to convey is that the returned user pointer is to be used by the kernel itself only, because we do not control how the bounds are extended for representability purposes. This is fine inside the kernel as we generally cannot do better (and have enough privilege to access any part of the address space), but it is not if userspace gets hold of this capability, as it could give access to arbitrary objects in addition to the one we intended. Additionally, we provide all possible Load/Store capability permissions as requested, which is again fine when the kernel controls the access but not necessarily if userspace does (e.g. we may want to provide Load but not LoadCap).
It is in this sense that the user pointer is "privileged" (because only the kernel should use it), but I agree that word is misleading. Maybe this is too subtle to convey in the naming. Since there are very few places in which the kernel creates user pointers for userspace (I think just binfmt_elf + mmap & co, where the CHERI API should be used directly instead of this one), the risks of accidental use of this function may be low enough that we can keep the name simple. Definitely looking for opinions on this!
Jumping here on this one to hopefully keep the discussion in a single thread...
So what we are looking at is capability with potentially elevated permissions and extended boundaries under sole kernel control... How about create_unrestricted_user_ptr instead ? or create_relaxed_user_ptr ?
"unrestricted" sounds deceiving as bounds and permissions are restricted, though not precisely. "relaxed" sounds a little bit strange for a pointer :D
That said these are inspiring, how about "loose"? "make_loose_user_ptr()"? It is hard to understand what that would refer to outside of the CHERI context, but I'm not sure we can do much better.
That still leaves it bit vague (as per your comment re: restricted bounds and permissions). This is tricky to get it right. 'managed' pop into my mind at some point: as the capability created will be handled internally by the kernel only, but it does not sound entirely appealing either. That said, I think I am out of 'reasonable' ideas at this point, sadly.
--- BR B.
Kevin