Hacker News new | past | comments | ask | show | jobs | submit login

Getting CHERI protection for security violations seems a bit like hitting the jackpot on a slot machine.

You need a CHERI OS on a CHERI CPU running software compiled with a CHERI aware compiler.

Doesn’t Rust also provide buffer overrun protection, without needing a special OS or CPU instruction set? Isn’t it a better ROI to rewrite the software on Rust, and not have to change anything else?

Can the same benefit be achieved by replacing CHERI CPU with a virtual machine runtime, or building support in LLVM IR?




> Doesn’t Rust also provide buffer overrun protection, without needing a special OS or CPU instruction set?

No, because there’s still quite a lot of (inevitable) Unsafe Rust code floating around, and the compiler can’t protect these from memory-related errors. In fact there are some ongoing discussions and progress to support CHERI in Rust:

[0] https://faultlore.com/blah/fix-rust-pointers/

[1] https://tratt.net/laurie/blog/2022/making_rust_a_better_fit_...

[2] https://archive.fosdem.org/2023/schedule/event/rust_a_rusty_...


So using Rust without using unsafe, is akin to using CHERI while ensuring the toolchain and hardware has support.

If we can be careful enough to use Rust minus unsafe, then you’re getting all the benefit without needing special hardware.

I guess my problem with this approach is that it’s not a drop-in replacement. Something will get missed and you’ll lose any CHERI guarantees along with that.

It would be cool to have a QEMU CPU with CHERI support to test some of these scenarios.


VMware virtualized x86 without hardware support, so it probably can be done. That doesn't mean it would be easy or it would be as performant as with hardware support.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: