4 ms·

Coming from a position knowing essentially nothing about computer architecture or compiler fundamentals CHERI seems like a bandaid in the same way that garbage

by klysm 5y ago

Coming from a position knowing essentially nothing about computer architecture or compiler fundamentals CHERI seems like a bandaid in the same way that garbage collection is a bandaid. I may be way off base, but it feels like the things CHERI ensures at “run time” _are_ enforceable at “compile time”. I’m not saying it doesn’t have a place though - we definitely don’t live in a world we’re such things are enforced so we need systems to check things at run time. It looks like a good solution but doesn’t feel like the “right” thing. Am I getting the right idea of what it’s purpose is?

staticassertion 5y ago
I think there's two important things to note here. 1. Bandaids are critical. We can't just fix the billion lines of C code out there by replacing it - we need strategies that wholesale destroy bug classes. CHERI does that. If you concretely removed temporal unsafety from all of an operating system's userland, just by recompiling, you'd have done the world a great service. 2. CHERI is very strong. It's not like some mitigation techniques, which rely on increasingly niche thread models (ASLR makes less and less sense as the world pushes towards "send code, not data" - to be fair, pax/grsec explicitly noted this 20 years ago, so it's hardly the fault of ASLR). CHERI totally wrecks spatial memory unsafety. That's fucking huge. The death of buffer overflows. Combined with other techniques like PAC, the memory unsafety threat becomes seriously less critical, or at least that's my position on it - would love to hear someone point out why I'm overly optimistic on this. In theory you could remove all bounds checking from code and leave it up to the hardware to enforce. It also is just sane. Like, I think containers are "sane" - they finally split the OS into disparate pieces. I think that NX is sane - why should memory be RWX by default? "A pointer for an allocation can dereference memory anywhere in the address space" is not sane, so hardware enforcing sanity is good. Where we can enforce sanity, we should. CHERI does that imo. Also, idk, even in memory safe languages it's not like bounds just go away. You get compile time assurances that either the bounds are gone and that's safe, or they're not gone and that's safe.
- kibwen 5y ago
  > We can't just fix the billion lines of C code out there by replacing it - we need strategies that wholesale destroy bug classes. Won't any C code making use of int-to-pointer casts fail to work on CHERI? And isn't that a property of virtually every C codebase in existence? It sounds like that code will need to be rewritten either way. > CHERI totally wrecks spatial memory unsafety. That's fucking huge. The death of buffer overflows. You'll have to elaborate on what PAC is, but leaving use-after-free/temporal memory unsafety on the table is a pretty conspicuous hole. If the answer for that involves runtime overhead, then it will be tough to sell moving to a new architecture as opposed to just using runtime mitigations on existing architectures (or, at the limit, rewriting the important bits in Rust).
  - Gankra 5y ago
    No, as my article notes, because C has a dozen slightly different definitions for "integers that are basically pointers" they were able to keep size_t 64-bit and make intptr_t into a pointer-sized integer and mark it as something the compiler should manipulate as if it was 'void*' (because it is as far as CHERI is concerned). This is still a messy hack but it vaguely functions. Rust doesn't have this luxury because it only defines an exact-pointer-sized integer, so it has to map usize to intptr_t and bloat up everything really badly.
  - pjmlp 5y ago
    CHERI already has a working version of FreeBSD, so apparently not every C codebase in existence. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheribsd.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... And plenty of other C and C++ software as well, if you follow those links.
  - saagarjha 5y ago
    'Gankra answers the cast part but for the other question: PAC is "pointer authentication codes", which is pretty much what it sounds like. It's a CFI+data integrity protection measure. Re: temporal memory safety, I don't think MTE solves everything but my understanding was you can revoke a capability for a region when the memory is freed and then mint it with a new one when allocating it out again, which would make stale pointers to it/UAF fault on access. Will have to check what the exact details are.

by klysm 5y ago

staticassertion 5y ago

I think there's two important things to note here. 1. Bandaids are critical. We can't just fix the billion lines of C code out there by replacing it - we need strategies that wholesale destroy bug classes. CHERI does that. If you concretely removed temporal unsafety from all of an operating system's userland, just by recompiling, you'd have done the world a great service. 2. CHERI is very strong. It's not like some mitigation techniques, which rely on increasingly niche thread models (ASLR makes less and less sense as the world pushes towards "send code, not data" - to be fair, pax/grsec explicitly noted this 20 years ago, so it's hardly the fault of ASLR). CHERI totally wrecks spatial memory unsafety. That's fucking huge. The death of buffer overflows. Combined with other techniques like PAC, the memory unsafety threat becomes seriously less critical, or at least that's my position on it - would love to hear someone point out why I'm overly optimistic on this. In theory you could remove all bounds checking from code and leave it up to the hardware to enforce. It also is just sane. Like, I think containers are "sane" - they finally split the OS into disparate pieces. I think that NX is sane - why should memory be RWX by default? "A pointer for an allocation can dereference memory anywhere in the address space" is not sane, so hardware enforcing sanity is good. Where we can enforce sanity, we should. CHERI does that imo. Also, idk, even in memory safe languages it's not like bounds just go away. You get compile time assurances that either the bounds are gone and that's safe, or they're not gone and that's safe.

kibwen 5y ago
> We can't just fix the billion lines of C code out there by replacing it - we need strategies that wholesale destroy bug classes. Won't any C code making use of int-to-pointer casts fail to work on CHERI? And isn't that a property of virtually every C codebase in existence? It sounds like that code will need to be rewritten either way. > CHERI totally wrecks spatial memory unsafety. That's fucking huge. The death of buffer overflows. You'll have to elaborate on what PAC is, but leaving use-after-free/temporal memory unsafety on the table is a pretty conspicuous hole. If the answer for that involves runtime overhead, then it will be tough to sell moving to a new architecture as opposed to just using runtime mitigations on existing architectures (or, at the limit, rewriting the important bits in Rust).
- Gankra 5y ago
  No, as my article notes, because C has a dozen slightly different definitions for "integers that are basically pointers" they were able to keep size_t 64-bit and make intptr_t into a pointer-sized integer and mark it as something the compiler should manipulate as if it was 'void*' (because it is as far as CHERI is concerned). This is still a messy hack but it vaguely functions. Rust doesn't have this luxury because it only defines an exact-pointer-sized integer, so it has to map usize to intptr_t and bloat up everything really badly.
- pjmlp 5y ago
  CHERI already has a working version of FreeBSD, so apparently not every C codebase in existence. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheribsd.html https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... And plenty of other C and C++ software as well, if you follow those links.
- saagarjha 5y ago
  'Gankra answers the cast part but for the other question: PAC is "pointer authentication codes", which is pretty much what it sounds like. It's a CFI+data integrity protection measure. Re: temporal memory safety, I don't think MTE solves everything but my understanding was you can revoke a capability for a region when the memory is freed and then mint it with a new one when allocating it out again, which would make stale pointers to it/UAF fault on access. Will have to check what the exact details are.