3 ms·

CHERI would defend against access to internal data structures without having to bounce between address spaces, FWIW.

• mcculley 1y ago
  Please elaborate.
  • quotemstr 1y ago
    fopen would hand out a FILE* without capabilities to do anything with the resulting data structure, but libc itself could work with it. Libraries would get the same kind of memory protections processes do today.
    • purplesyringa 1y ago
      How would libc get a FILE* pointer with capabilities back from a FILE* passed by the user?
      • quotemstr 1y ago
        libc allocates the FILE* from an array of them or a heap of some sort. It has a private capability on the start of the array and so can recover a full-capability pointer by offsetting its private capability by the distance encoded in the user FILE*. No actual memory access required, I'd think. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/202306-plarch-library-based-compartmentalisation.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/202306...
        • dwattttt 1y ago
          This sounds about right. Under CHERI when you're returning a pointer from a function, you can choose to limit its valid dereferencable range, I imagine all the way to 0 (i.e. it can't be dereferenced). When the pointer is passed back into libc, libc can combine the pointer with an internal capability that has the actual size/range of the structure. This isn't _too_ different to having libc just hand out arbitrary integers as FILE; libc has to have some way to map the 'FILE' back to the real structure.