Hacker News Reader

Comment by nwf | Hacker News Reader

> it doesn't matter too much whether the emulator is CHERI or not since Rust itself lets me express memory safety in the type system

You might be interested in a very timely blog post: https://cheriot.org/cheri/myths/2024/08/28/cheri-myths-safe-...

View on HN

> CHERI doesn’t guarantee that your code is free from memory-safety errors, it guarantees that any memory-safety bugs will trap and not affect confidentiality or integrity of your program.

That sounds an awful lot like ensuring your code is free from memory-safety errors. A language which always traps on erroneous memory accesses is a memory safe language, so if CHERI really guarantees what that sentence says, then C on CHERI hardware is memory safe.

C on CHERI hardware is not magically memory-safe. CHERI just traps on memory-unsafety.

If it traps on all things that would otherwise be memory-unsafety then it is memory safe. If trapping doesn't count as memory safe, then e.g. Rust isn't memory safe, since it traps on OOB accesses to arrays.

CHERI capabilities are memory-safe, because they trap on any attempted memory unsafety. Safe Rust is memory-safe, assuming all the underlying Unsafe Rust traps on any attempted memory unsafety.

C is not memory-safe, even on CHERI, because it has to be trapped by CHERI; it cannot catch itself.

Safe Rust is memory-safe on its own, because memory unsafety can only be introduced by Unsafe Rust; Safe Rust has no unsafe operations. Assuming the Unsafe Rust is sound, Safe Rust cannot cause memory safety to be violated on its own. (You can do `/proc/mem` tricks on Linux, but that's a platform thing...)

I'm not sure if we are talking past each other or what.

1. Non-unsafe rust is memory-safe because otherwise unsafe operations (e.g. out-of-bounds accesses on arrays) are guaranteed to trap.

2. A typical C implementation on typical non-CHERI hardware is not safe because various invalid memory operations (e.g. out-of-bounds, use after free) may fail to trap.

3. A typical C implementation on CHERI hardware guarantees that all otherwise memory-unsafe operations trap.

I think we both agree on #1 and #2. Am I wrong about #3? If I'm not wrong about #3, then what makes you say that #3 is not memory-safe?

In #3, the C implementation is not what's memory-safe, that's what I've been trying to say. CHERI is memory-safe, but the C isn't what actually guarantees the memory safety. You can dereference a null pointer on CHERI. The architecture can trap it, but that doesn't change the fact that C actually attempted to do it and therefore would not be memory-safe. Only the system as a whole prevents the memory unsafety.

Aha. I think we agree. I originally said "C on CHERI hardware is memory safe" by which I meant "the system as a whole of (C code + CHERI hardware)" is memory safe, but you seemed to think I meant (C code) is memory safe.

I actually had thought you meant something like "the C language is memory safe when run on CHERI". If you mean that running a C program on CHERI prevents memory safety from actually being broken, then yeah, I guess we do agree. On CHERI, even if the C program alone isn't completely sound, and so attempts to violate memory safety, the attempt won't actually succeed, so memory safety won't actually be violated.

I'm not talking about writing robust software, I'm talking about having fun - Rust's type system already provides the type of fun that I would have gotten from a CHERI emulator. That's why only getting to own physical CHERI hardware would truly pique my interest.

That article indeed is quite timely. I do agree with it. Slightly different angle though.

Reply on news.ycombinator.com