3 ms·

This article feels very wrong. There is so much of exposing the underlying hardware CHERI functionality to the user in everything suggested in this article. It

This article feels very wrong. There is so much of exposing the underlying hardware CHERI functionality to the user in everything suggested in this article. It would never fly in Rust. This post feels completely written from the perspective of C-isms rather than from the perspective of Rust. This paragraph in particular: > Fortunately, I believe that Aria's proposal can be adapted such that a Rust-for-CHERI can cope with both pure capability and hybrid modes. In essence, one needs explicit, separate, types for both traditional pointers and capabilities. mut () suffices for the former and a wrapper of some sort, e.g. Cap<mut ()> for the latter. Conceptually this means that mut () is no longer the root of the integer/pointer type system, because one cannot convert Cap<mut ()> to mut () without losing information (the capability's extra bits). My gut feeling is that in practice, most code can treat mut () as the root of the integer/pointer type system, and only code which really cares about capabilities need know of Cap's existence. An additional nice property is that one will be able to write Rust code in a way that can be agnostic about pure capability mode (where size_of::<mut ()>() == size_of::<Cap<mut ()>>()) and hybrid mode (where size_of::<mut ()>() < size_of::<Cap<mut ()>>()). Capabilities should not be visible to users of the Rust language what-so-ever and should only exist in the compiler, and nowhere else. The more correct solution is to just forbid "hybrid" modes, which seem only useful for C projects where there is a lot of legacy code. Something Rust doesn't have. The author also admits as such in their footnote on hybrid mode having "many uses": > In the context of Rust, it's also worth asking whether it's worth making all pointers double width (which, though perhaps small, will undoubtedly have measurable memory and performance costs). After all, most Rust code is safe, and the compiler can guarantee that pointers can't be easily misused for things like buffer overruns. Rather, I see the main utility for a language like Rust being to impose various "sub-process" like compartments, with only relatively small portions of the code needing to use capabilities explicitly. It is perfectly acceptable to have all Rust-on-CHERI systems to have double width pointers in my opinion. This wouldn't affect software on any existing supported platforms. If you're writing new Rust code, for a CHERI system, but not using capabilities, I would wonder why you're using the platform in the first place.

ltratt 5y ago
I agree that you don't want non-CHERI Rust code to have to know about capabilities in any way. However, if you are using Rust for CHERI, you need to have some access to capability functions otherwise, even in pure capability mode, you can't reduce a capability's permissions. For example, if you want to write `malloc` in purecap Rust, you'll probably want to hand out capabilities that point to blocks of memory with bounds that only cover that block: you need some way to say "create a new capability which has smaller bounds than its parent capability." As to the utility of hybrid mode, I politely disagree. For example, is it useful for safe Rust code to always pay the size penalty of capabilities when you've proven at compile-time that they can't misuse the underlying pointers? A very different example is that hybrid mode allows you to meaningfully impose sub-process like compartments (in particular with the `DDC` register, which restricts non-capability code to a subset of the virtual address space; see also the `PCC` register and friends). Personally, I think that this latter technique holds a great deal of potential.
- mlindner 5y ago
  > For example, is it useful for safe Rust code to always pay the size penalty of capabilities when you've proven at compile-time that they can't misuse the underlying pointers? This seems like it's impossible though? How can you prove at compile time that all software that your safe Rust calls doesn't corrupt pointers? Don't you need capabilities in the Rust to ensure that if such software does something nefarious, the Rust code catches it before doing something untoward? (Not to mention the risk of compiler bugs causing something.)
  - saagarjha 5y ago
    If you’re passing a pointer to safe Rust code, with the capability bound encoded into something “native” to the language, then you don’t need hardware capabilities at all.
    - connicpu 5y ago
      You'd still need access to the capability interface to perform that checking at the unsafe/safe boundary

ltratt 5y ago

I agree that you don't want non-CHERI Rust code to have to know about capabilities in any way. However, if you are using Rust for CHERI, you need to have some access to capability functions otherwise, even in pure capability mode, you can't reduce a capability's permissions. For example, if you want to write `malloc` in purecap Rust, you'll probably want to hand out capabilities that point to blocks of memory with bounds that only cover that block: you need some way to say "create a new capability which has smaller bounds than its parent capability." As to the utility of hybrid mode, I politely disagree. For example, is it useful for safe Rust code to always pay the size penalty of capabilities when you've proven at compile-time that they can't misuse the underlying pointers? A very different example is that hybrid mode allows you to meaningfully impose sub-process like compartments (in particular with the `DDC` register, which restricts non-capability code to a subset of the virtual address space; see also the `PCC` register and friends). Personally, I think that this latter technique holds a great deal of potential.

mlindner 5y ago
> For example, is it useful for safe Rust code to always pay the size penalty of capabilities when you've proven at compile-time that they can't misuse the underlying pointers? This seems like it's impossible though? How can you prove at compile time that all software that your safe Rust calls doesn't corrupt pointers? Don't you need capabilities in the Rust to ensure that if such software does something nefarious, the Rust code catches it before doing something untoward? (Not to mention the risk of compiler bugs causing something.)
- saagarjha 5y ago
  If you’re passing a pointer to safe Rust code, with the capability bound encoded into something “native” to the language, then you don’t need hardware capabilities at all.
  - connicpu 5y ago
    You'd still need access to the capability interface to perform that checking at the unsafe/safe boundary