<story><title>Making Rust a Better Fit for Cheri and Other Platforms</title><url>https://tratt.net/laurie/blog/2022/making_rust_a_better_fit_for_cheri_and_other_platforms.html</url></story><parent_chain></parent_chain><comment><author>kibwen</author><text>The OP links Gankra&amp;#x27;s first article, but don&amp;#x27;t miss the follow-up where she actually implemented some of these ideas as proof-of-concepts in the stdlib and compiler: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;gankra.github.io&amp;#x2F;blah&amp;#x2F;tower-of-weakenings&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;gankra.github.io&amp;#x2F;blah&amp;#x2F;tower-of-weakenings&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Making Rust a Better Fit for Cheri and Other Platforms</title><url>https://tratt.net/laurie/blog/2022/making_rust_a_better_fit_for_cheri_and_other_platforms.html</url></story><parent_chain></parent_chain><comment><author>dathinab</author><text>I think there are some problems in the article.&lt;p&gt;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.&lt;p&gt;So yes more is needed for supporting CHERI but:&lt;p&gt;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::&amp;lt;somethingCHERI&amp;gt;`)&lt;p&gt;2. &amp;quot;Rust&amp;#x27;s integer type hierarchy&amp;quot; There is no type hierarchy in the sense there is in C&amp;#x2F;C++ as there is no sub-typing of integers (i.e. auto-conversions) in rust. Same is true for pointers so I don&amp;#x27;t think it makes sense to call `&lt;i&gt;mut ()` the &amp;quot;root of the...&amp;quot;. (Also if anything that would be `&lt;/i&gt;const ()`). Similar it&amp;#x27;s more a void-pointer (through not quite the same) then a `uintptr_t`. To quote Aria: &amp;quot;I don’t think Rust needs to define a moral equivalent to intptr_t [...]&amp;quot;.&lt;p&gt;3. The 129th bit is a &amp;quot;secret&amp;quot; implementation detail. So not representing it is intended. if your code relies on somehow detecting if it&amp;#x27;s set or not to work correctly you are doing something wrong. (Through maybe for testing&amp;#x2F;asserts, still at most a CHERI specific method under std::arch.)&lt;p&gt;4. The proposed scratch design for hybrid mode fundamentally doesn&amp;#x27;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&amp;#x2F;C++ (Through I have to read into it first). Anyway hybrid mode is as far as I can tell irrelevant for &amp;quot;pure&amp;quot; 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 &amp;quot;normal(capability)&amp;quot; pointers. Only handling &amp;quot;normal&amp;quot; pointers in rust (which all have capabilities when compiled for CHERI).</text></comment>