Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

blog: add post on capability ptr #109

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

blog: add post on capability ptr #109

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fb0d75d
blog: add post on capability ptr
bradjc Jan 16, 2025
7e22797
tt58: update descriptions
bradjc Jan 30, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions _posts/2025-01-16-talking-tock-58.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
---
title: Talking Tock 58
subtitle: New pointer type in the kernel
authors: bradjc
---

Correctly expressing data types in Rust between userspace and the kernel with
correctly captured semantics is challenging as different hardware platforms
provide different data representations. The common example of this is 32-bit
platforms versus 64-bit platforms which store different sized types in registers
and therefore provide a different amount of data between userspace and the
kernel. Emerging platforms, for example hardware with CHERI support, complicate
this further. With [pull request #4174](https://github.com/tock/tock/pull/4174)
merged, Tock has taken a step to improve this by adding `CapabilityPtr`, a type
within the kernel to clearly express when data within the kernel is a pointer.

The `CapabilityPtr` Type
------------------------

Fundamentally this type stores a pointer to memory. The name "capability"
signifies this type also captures the validity of that pointer and whether the
holder of the pointer can actually use the pointer to access memory.

Traditionally, a valid pointer in `unsafe` Rust always has the capability to be
dereferenced. That is, the hardware will (at least try to) access the referenced
memory. `CapabilityPtr` expands this abstraction, and enables software to track
whether hardware will permit the memory access, if the hardware has such
restrictions.

Support for CHERI
-----------------

The primary driver for adding the `CapabilityPtr` type is the
[CHERI](https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/) extension for
hardware architectures. With CHERI, hardware can track whether a pointer can be
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When someone talks about running "Rust on CHERI", they're usually referring to a pure-capability CHERI ABI. However, @LawrenceEsswood is porting the Tock kernel to a hybrid CHERI ABI, which has some different properties. One of those properties is that in hybrid CHERI, a language's default pointer types are not CHERI capabilities -- which is the reason why we need CapabilityPtr. In purecap CHERI, we don't need CapabilityPtr, as *mut T can do the same job.

We should probably clarify that CapabilityPtr is to support hybrid CHERI, otherwise this may be confusing for readers familiar with the upstream efforts to port Rust to CHERI.

(Lawrence, please correct me if I'm wrong about this).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try to clarify this, but maybe this indicates this post is helpful as this difference is pretty opaque to me.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jonathan is correct. At the end of the day both *const T and CapabilityPtr are types in an abstract machine, and what hardware representation they have is always with respect to a given ABI.

"Legacy" CHERI ABI says that these should be lowered to an integer address
Hybrid CHERI ABIs say that *const T should be lowered to an address but CapabilityPtr to a CHERI capability.
Purecap CHERI ABIs say that both should be lowered to a CHERI capability.

dereferenced. The metadata for that tracking is stored alongside the pointer
address in hardware registers. Tock is targeting a hybrid CHERI ABI which
supports both a traditional pointer and pointers with the CHERI metadata. With
the `CapabilityPtr` type, Tock now has a mechanism to represent these pointers
with metadata that are larger than the machine's `usize` yet `CapabilityPtr`
still represents a single register.

Adding `CapabilityPtr` is only a first step towards support for CHERI in Tock.
Additional pull requests will fill in the remaining support needed in the Tock
kernel for this hardware support.