3 ms·
> 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 o
by aidenn0 2y ago
> 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.
- LoganDark 2y agoC on CHERI hardware is not magically memory-safe. CHERI just traps on memory-unsafety.
- aidenn0 2y agoIf 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.
- LoganDark 2y agoCHERI 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...)
- aidenn0 2y agoI'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?
- LoganDark 2y agoIn #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.
- aidenn0 2y agoAha. 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.
- LoganDark 2y agoI 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.