context-capabilities-initiative
context-capabilities-initiative copied to clipboard
nikomatsakis
Track blog posts
Blog posts have been written by members of the community, this is an issue gathering them so we can reference them later on:
- https://blog.sunfishcode.online/context-brainstorming/
- https://blog.sunfishcode.online/the-spectrum-from-namespaces-to-values/
- https://jam1.re/blog/thoughts-on-contexts-and-capabilities-in-rust
- 2021-12-26 "Futuristic Rust: context emulation" https://haibane-tenshi.github.io/rust-contexts/
- 2022-07-14 "Futuristic Rust: context emulation, part 2" https://haibane-tenshi.github.io/rust-contexts2/
- 2023-01-24 "Capability-Safety I: Prelude" https://blog.yoshuawuyts.com/capabilities-1/
https://www.memorysafety.org/blog/gary-guo-klint-rust-tools/ talks about representing various contexts in the kernel. They briefly discuss contexts/capabilities as well:
People familiar with paradigms in Rust might also wonder if a token type, or some possible context and capabilities extension might help with this, but unfortunately it would not help this scenario. You can't do negative reasoning with token types thus a token-based approach would require almost all functions to carry tokens in their signatures.
In the end, we took none of the above approaches. There are no safeguards in the kernel's Rust API abstractions that prevent sleep-in-atomic-context from happening. This means that if you compile your kernel with preemption count tracking disabled, it's possible to write a Rust driver with only safe code that results in a use-after-free. Pragmatism is prioritised over soundness.