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 ?