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.
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.
quotemstr|7 months ago
See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/202306...
dwattttt|7 months ago
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.