zlacker

> Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us.

Have you found that the relative difficulty of bootstrapping Rust on a new architecture, as mentioned in [1], has hindered your team's ability to research this? Or is it not as bad with CHERI on ARM, because aarch64 is already a Rust tier 1 platform?

[1]: https://drewdevault.com/2022/01/15/2022-01-15-The-RISC-V-exp...

>>mwcamp+(OP)
I've bootstrapped Rust for RISC-V on FreeBSD, it's not that bad, the issues I faced were solely porting issues, not bootstrapping issues. I've certainly not had cross-compiling issues like Drew. The awful part about porting Rust is that you need Rust bindings for every type and function in your system's libc, which is fine if your OS+libc combination is already supported (though even then 32-bit and 64-bit need some separate implementation bits), but a real pain if your OS isn't yet supported. Rust on CHERI has the additional complexity of a poor design decision in the language that defines usize as a pointer-sized integer, conflating integers and pointers, rather than providing both size_t and uintptr_t equivalents like C has; see https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-... for a discussion of this and ways to resolve it without breaking existing software on non-CHERI which, as you might expect, is to introduce a new uptr type for the rare cases when a usize holds a pointer not an offset/length/machine word-sized integer, allowing a usize to be used in its place on non-CHERI architectures (at least for existing editions) but not for CHERI architectures. Someone needs to do that engineering though and it's not a priority for us.