Theoretically if you had a kernel written in Rust, I suppose you could implement the system call interface such that all pointers passed to the kernel from user

Theoretically if you had a kernel written in Rust, I suppose you could implement the system call interface such that all pointers passed to the kernel from user space would be considered "borrowed" under the Rust type system, and then have all your "return to user space" mechanisms recognised by the compiler as terminating their lifetime. I'm not sure if that's enough though, considering that, in general, the kernel can't assume anything passed to it by reference via a system call isn't mutated by another userland thread. Furthermore, even if everything were written in Rust, the kernel can't just trust that a userland process was actually compiled in a way that faithfully employed Rusts compile-time safety guarantees... so I think any notion of shared garbage collection is tricky without a program loader that did code verification. Microsoft have done some work in this area with their Singularity and Midori projects[0]. Singularity in particular eliminates hardware isolation between processes. I think the simple answer here is that the kernel should be copying anything passed to it by reference if it intends to do anything beyond a single atomic read operation. This is why, on Linux for instance, send() can't return to user space until the data has been copied in to kernel controlled memory, and why we have nice things like splice() and sendfile() to deal with the performance hit of doing so for common cases. [0] https://en.wikipedia.org/wiki/Midori_%28operating_system%29 https://en.wikipedia.org/wiki/Midori_%28operating_system%29