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

21–30 of 42 posts

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

#21

Post by mjw1007 »

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…

Right, better control of the index type can help you say what you mean, and help the typechecker catch more mistakes.

If I have an array representing a single-byte lookup table, it would be nice if I could say that the array's type is array-indexed-by-u8 rather than array-indexed-by-usize.

Ada did this well: it even lets you declare an array whose index is some enumerated type.

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

#22

Post by est31 »

masklinn wrote: post #17
pwdisswordfish9 wrote: post #6

Earlier quoted context omitted.

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

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

Which totally makes sense. u8 means 256 bytes of addressable memory. You might design chips with such limited memory, but maybe high level (read non assembly) languages are not the right tool for targetting them.

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

#24

Post by roblabla »

djmcnab wrote: post #18
ltratt wrote: post #15

Earlier quoted context omitted.

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.

Problem is, there's lots of unsafe code that casts *mut T to &mut T (usually after checking T is valid and whatnot). If &mut T didn't use capabilities, this kind of unsafe code would end up not taking advantage of the CHERI capability checking, which would be unfortunate.

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

#25

Post by dathinab »

I think there are some problems in the article.

The main point of the referenced article by Aria Beingessner is Pointer Provenance. That this also helps out with enabling potential support for CHERI is a nice (and intended) side effect.

So yes more is needed for supporting CHERI but:

1. The non-address parts, if and how you can access them are fully CHERI specific. Any such code should (for now) not be Generic Rust but architecture specific extensions. (E.g. live in `std::arch::`)

2. "Rust's integer type hierarchy" There is no type hierarchy in the sense there is in C/C++ as there is no sub-typing of integers (i.e. auto-conversions) in rust. Same is true for pointers so I don't think it makes sense to call `mut ()` the "root of the...". (Also if anything that would be `const ()`). Similar it's more a void-pointer (through not quite the same) then a `uintptr_t`. To quote Aria: "I don’t think Rust needs to define a moral equivalent to intptr_t [...]".

3. The 129th bit is a "secret" implementation detail. So not representing it is intended. if your code relies on somehow detecting if it's set or not to work correctly you are doing something wrong. (Through maybe for testing/asserts, still at most a CHERI specific method under std::arch.)

4. The proposed scratch design for hybrid mode fundamentally doesn't work because of pointer provenance. Pointers need to be build-in types. So in hybrid mode you now would have 4 instead of 2 pointer types. Also given that you would want to use all of them in normal code you also would have 4 instead of 2 reference types. As far as I can tell this is also a messy nightmare to use in C/C++ (Through I have to read into it first). Anyway hybrid mode is as far as I can tell irrelevant for "pure" rust applications and only becomes relevant when linking against non-capability-supporting FFI. EDIT: Provenance is often partially lost at FFI boundary anyway and you probably would want to special type the non-capability pointers and then at the boundary convert them to "normal(capability)" pointers. Only handling "normal" pointers in rust (which all have capabilities when compiled for CHERI).

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

#26

Post by djmcnab »

roblabla wrote: post #24
djmcnab wrote: post #18

Earlier quoted context omitted.

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.

Problem is, there's lots of unsafe code that casts *mut T to &mut T (usually after checking T is valid and whatnot). If &mut T didn't use capabilities, this kind of unsafe code would end up not taking advantage of the CHERI capability checking, which would be unfortunate.

I don't think this is actually a problem, since when casting from `&mut T` to `*mut T`, the returned pointer can only access the data (the T value) directly behind the reference.

The raw pointer would be synthesised with the capability for only the pointee of the original reference.

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

#27

Post by ltratt »

djmcnab wrote: post #18
ltratt wrote: post #15

Earlier quoted context omitted.

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.

It's absolutely possible, because the hardware doesn't care about your compilation model: you can mix normal pointers and capabilities as you wish. A challenge is that it's easy to go from capability -> pointer, but harder to go from pointer -> capability -- where do the extra capability bits come from? CHERI C provides a default ("inherit capability bits from the DDC") but I'm not sure that's what I would choose to do.

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

#28

Post by zozbot234 »

dathinab wrote: post #25

I think there are some problems in the article. The main point of the referenced article by Aria Beingessner is Pointer Provenance. That this also helps out with enabling potential support for CHERI is a nice (and intended) side effect. So yes more is needed for supporting CHERI but: 1. The non-address parts, if and how you can access them are fully CHERI specific. Any such code should (for now) not be Generic Rust b…

> So in hybrid mode you now would have 4 instead of 2 pointer types. Also given that you would want to use all of them in normal code you also would have 4 instead of 2 reference types.

We'd need more pointer types to support other segmented architectures anyway. Real mode x86 has __near, __far and __huge pointer types.

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

#29

Post by Ar-Curunir »

mjw1007 wrote: post #21
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…

Right, better control of the index type can help you say what you mean, and help the typechecker catch more mistakes. If I have an array representing a single-byte lookup table, it would be nice if I could say that the array's type is array-indexed-by-u8 rather than array-indexed-by-usize. Ada did this well: it even lets you declare an array whose index is some enumerated type.

> _ it even lets you declare an array whose index is some enumerated type._

You can do this in Rust also: make a custom newtype wrapper for your array, and impl Index for the wrapped array.

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

#30

Post by saagarjha »

mlindner wrote: post #16
ltratt wrote: post #15

Earlier quoted context omitted.

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, t…

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.
Post reply on HN