Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Rust a Better Fit for Cheri and Other Platforms

tratt.net

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Making Rust a Better Fit for Cheri and Other Platforms

#11

Post by dgb23 »

ekhjarta wrote: post #7
pwdisswordfish9 wrote: post #6

Earlier quoted context omitted.

What’s wrong with .try_into:: ().unwrap()?

It fails at runtime and not at compile time and it only fails if the value is out of range, so you have to test with large enough values to trigger the assertion during testing. We want to be able to index with integer types that are smaller than or has the same size as usize, but not with integer types that are larger than usize. And we want those checks at compile time.

Unwrap isn’t an evil thing to avoid completely. The type system cannot understand all invariants, but you can, and you can make sure they are correctly implemented.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#12

Post by bestouff »

davidhyde wrote: post #2

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that co…

You could use TiVec[1], TiSlice[1] or TiBitset[2] (shameless plug) to have datastructures indexed by the type you need, all checked at compile type. All you need is a From/Into implementation for your chosen index type.

1: https://lib.rs/crates/typed-index-collections

2: https://lib.rs/crates/tibitset

Re: Making Rust a Better Fit for Cheri and Other Platforms

#13

Post by ATsch »

davidhyde wrote: post #2

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that co…

> Using a usize often seems wasteful for indexing into small arrays and slices

The opposite is often the case, as the architecture may not support offsetting a pointer by those sizes, requiring lots of casting in tight loops. Making that explicit makes the programmer aware of this.

This is one major reason that C compiler developers want all overflow to be undefined behavior, as it allows them to upgrade for loops that use smaller index types to larger ones.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#14

Post by mlindner »

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. Capmut ()> for the latter. Conceptually this means that mut () is no longer the root of the integer/pointer type system, because one cannot convert Capmut ()> 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::mut ()>>()) and hybrid mode (where size_of::mut ()>() 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.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#15

Post by ltratt »

mlindner wrote: post #14

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…

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.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#16

Post by mlindner »

ltratt wrote: post #15
mlindner wrote: post #14

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…

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 bo…

> 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.)

Re: Making Rust a Better Fit for Cheri and Other Platforms

#17

Post by masklinn »

pwdisswordfish9 wrote: post #6
davidhyde wrote: post #2

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that co…

What’s wrong with .try_into:: ().unwrap()?

.into() will work for u8 and u16, as rust assumes >= 16b pointers.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#18

Post by djmcnab »

ltratt wrote: post #15
mlindner wrote: post #14

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…

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 bo…

One potential option I haven't seen mentioned is to make references (i.e. `&[mut] T`) not use capabilities, but raw pointers (`*(mut|const)`) to use capabilities. Since the compiler already guarantees that references are used correctly, at least theoretically this is best of all worlds.

Now it's possible that CHERI would make this impossible, but it's definitely an angle worth recognising.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#19

Post by samhw »

ekidd wrote: post #10
davidhyde wrote: post #2

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that co…

Rust really doesn't do implicit numeric conversion, and I suspect it would be hard to retrofit. But you could write a function i(...) that promoted u8, etc, to usize: v[i(my_u8_index)] This could be implemented as a compile-time check, with no runtime errors. You'd have to limit which types you support as indices if you want to be portable to platforms with tiny pointers, of course. I guess something like this might…

If you were going to do that, it may be easier just to implement `Index`/`IndexMut` over `u8`/`u16`/.. for whatever type (newtype if necessary) you're indexing into. I suppose it's hard to say without context though.

Re: Making Rust a Better Fit for Cheri and Other Platforms

#20

Post by edflsafoiewq »

pwdisswordfish9 wrote: post #6
davidhyde wrote: post #2

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that co…

What’s wrong with .try_into:: ().unwrap()?

It's hideous.
Post reply on HN