Earlier quoted context omitted.
> You can think of the creation syscalls as taking an implied handle to the Process's Job, which is an "object factory" similar to what you suggest. Implicit handles are not explicit handles, and capability security requires explicit handles. You're obviously familiar with capabilities and the problems inherent to breaking capability properties, so why violate them in this instance? You mention API usability, but mx_…
Yes, handles are partitioned per-process. Having them be unlikely to be reused or collide with small numbers (locally) helps avoid some common failure cases (somebody uses a fd after close but somebody else has opened something else that got the same fd and now you have two problems). Having them be harder to guess provides some (minor) additional defense against attempting to remotely exploit bugs in another process…
This could be handled in user space without affecting kernel structures using opaque structs and some runtime bookkeeping.
Alternately, Kernel fds could use the low order 24-bits for the descriptor itself, with top 8-bits reserved as an allocation count. When a given fd is closed, increment the counter for the next time it's allocated. You've reduced the chance of already rare misuse by 256 fold with requiring some kind of sparse data structure in the kernel.
Perhaps the current handle design is even harder to misuse, but how defensive should you be for accidental misuse like this?
> Having them be harder to guess provides some (minor) additional defense against attempting to remotely exploit bugs in another process.
I've never heard of this kind of exploit. Do you have an example?