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

31–40 of 42 posts

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

#31

Post by scns »

dgb23 wrote: post #9
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…

Code looks ugly should maybe not be a big concern in a language like Rust. It’s fundamentally ugly to begin with in many ways. And I think that’s fine because it is a language that is primarily about control. One could argue that this is beautiful in its own way. There’s a clarity and power in being explicit while the constraints let you move on with confidence.

Function over form. I think it makes a lot of sense in Rusts' domain.

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

#32

Post by saagarjha »

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…

> Capabilities should not be visible to users of the Rust language what-so-ever and should only exist in the compiler, and nowhere else.

One important use of Rust is operating systems, allocators, and JIT compilers where security is important and interacting with capabilities is expected. You’ll really want some way to represent them in the language for these usecases.

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

#33

Post by gpm »

saagarjha wrote: post #32
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…

> Capabilities should not be visible to users of the Rust language what-so-ever and should only exist in the compiler, and nowhere else. One important use of Rust is operating systems, allocators, and JIT compilers where security is important and interacting with capabilities is expected. You’ll really want some way to represent them in the language for these usecases.

Naively I think you can probably just expose interactions with them inside existing apis like "slice::split_at_mut", since the rust abstract machine already has the concept of pointers being able to access regions of memory.

You would probably have direct access to the primitives available, but discourage using them, because using them means non portable code.

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

#34

Post by dathinab »

zozbot234 wrote: post #28
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.

I'm but sure people care enough to add support for segmented architectures to rust.

I mean as far as I can tell you mainly find segmentation in very very old x86 servers.

I'm sure there are still legacy systems like that running, but this is unlikely to have anything to do with rust.

I mean even most Linux distros do no longer support being run on 32 bit arch (through they still tend to support running 32 bit applications on 64 bit arch).

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

#35

Post by connicpu »

saagarjha wrote: post #30
mlindner wrote: post #16

Earlier quoted context omitted.

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

You'd still need access to the capability interface to perform that checking at the unsafe/safe boundary

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

#36

Post by staticassertion »

ATsch wrote: post #13
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 th…

That seems easy to optimize out, especially given rust's mutability guarantees. If I have a u8 and I index into an array in a loop the compiler should be free to cast it to a usize above that loop, right?

The benefit being you can store much smaller structures, plus in the case of memory unsafety you reduce attacker control.

The vast majority of strings I personally use are certainly well under 2^32 bytes, and most are probably under 2^8.

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

#37

Post by [deleted] »

dgb23 wrote: post #11
ekhjarta wrote: post #7

Earlier quoted context omitted.

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.

[deleted]

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

#38

Post by [deleted] »

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…

[deleted]

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

#39

Post by saati »

> It's important to note that the cast warnings (or errors) are not enough on their own to help make code correct: additional auditing will be required. However, at the very least, this will give programmers a good idea of where to start auditing their code [4]. Some people might choose not to adapt their code, or find it too difficult to do so, but my guess is that most people will choose to do so.

I strongly doubt that most people would change their code for an ISA that barely exists.

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

#40

Post by saagarjha »

gpm wrote: post #33
saagarjha wrote: post #32

Earlier quoted context omitted.

> Capabilities should not be visible to users of the Rust language what-so-ever and should only exist in the compiler, and nowhere else. One important use of Rust is operating systems, allocators, and JIT compilers where security is important and interacting with capabilities is expected. You’ll really want some way to represent them in the language for these usecases.

Naively I think you can probably just expose interactions with them inside existing apis like "slice::split_at_mut", since the rust abstract machine already has the concept of pointers being able to access regions of memory. You would probably have direct access to the primitives available, but discourage using them, because using them means non portable code.

Right, the instances I'm mentioning are going to be parts of the codebase that are intended to be platform-specific.
Post reply on HN