This will happen soon, correct? We already have three calls to this function with no safety justification.

It's unclear to me what the safety conditions will look like (i.e. how we will prevent capsules from breaking isolation by copying CapabilityPtrs into userspace memory).

Technically, there are no safety requirements from rust's perspective (I would have voted "no" to making this interface unsafe) for the use of this type within the kernel. This type does not implement Deref, and is no more unsafe than the MPU configuration interfaces, which are not unsafe at present.

If we did decide that any of these might eventually be passed to the user, and there was a library invariant they should never be allowed access to kernel memory, I suppose it might say "This should never create an alias with any objects accessible by the kernel, apart from those accessed through the grant interface".

It's unclear to me what the safety conditions will look like (i.e. how we will prevent capsules from breaking isolation by copying CapabilityPtrs into userspace memory).

Part of the reason of why I added this comment is exactly because these and other details are unclear to me. There will be safety considerations, and this is a public API, and as such this is to serve as a deterrent for anyone to rely on any stable safety conditions at this point.

Technically, there are no safety requirements from rust's perspective (I would have voted "no" to making this interface unsafe) for the use of this type within the kernel.

In a system where capabilities serve as the only memory isolation mechanism, we must ensure that any untrusted code we're invoking (such as a process) cannot violate any of Rust's safety invariants. If arbitrary capabilities can flow across this boundary on a type-level (such as ones pointing into kernel memory, originating from capsules) either the boundary would need to be unsafe, or creating these capabilities must be.

Put differently, even though these types might be safe in isolation, this doesn't mean they're safe in the presence of other interfaces that rely on certain invariants holding for these types (such as Tock's userspace-kernel boundary). One such invariant should probably be that a CapabilityPtr must not have authority over kernel memory, although we might want even stronger invariants in practice.

My argument for them being unsafe relies on the premise that there might be an API that would allow capsules to smuggle capabilities into userspace. Will this API never exist?

This type does not implement Deref, and is no more unsafe than the MPU configuration interfaces, which are not unsafe at present.

I think this is the crux: I strongly believe that the MPU configuration interfaces ought to be unsafe, following this same reasoning. We have some much weaker argument for why it might be okay for them not to be unsafe: capsules shouldn't be able to get a hold of a reference the chip's MPU type, and as such they wouldn't be able to use those "safe" interfaces (similar to "capsules will never be able to pass a CapabilityPtr into userspace"). I disagree with this line of reasoning, and there likely is a way for capsules to get a reference like this. However, that is a different discussion, orthogonal to this PR.

I definitely agree with your premise that we have a library invariant whenever MPUs / CHERI are used that we do not allow the user access to kernel, and this very much can become language UB if the user trashes the kernel.

My objections were mostly that CHERI suddenly seems special as other MPU accesses are not considered unsafe, and on the practiically of marking the interface unsafe.

If we do mark the interface unsafe, we should surely justify at the call sites that we have enforced insolation, or else propagate unsafety requirements upwards. My suspicion is that isolation probably can't be locally argued and is likely a property of broad kernel correctness. Possibly, the scope of the entire core kernel, so we would either just have to admit defeat and say every function is unsafe, or instead lie at call sites and say we we can be certain we are not breaking safety here, even though the scope is far too broad to ever do so in full spirit.

TL;DR - this can be unsafe, but then a whole lot more should be too.

I think I agree to the above in spirit, although I believe we will be able to end up precisely drawing the line around unsafe interfaces, and hence don't agree with the generalization in the third paragraph.

In any case, let's wait on the follow-up PR that will introduce the reality of a real capability-hardware platform where these abstract concerns will manifest into tangible isolation properties / violations. Then we can revisit these call-sites and add appropriate documentation.