nwf-msr
commented
9 months ago Thank you for so clearly engaging so deeply with the CHERIoT ISA. I'm sorry that we haven't yet written a detailed rationale like big-CHERI has in their ISA.
By way of concrete examples,
- the "fast unsealer" library loads a capability bearing unseal permissions through PCC: https://github.com/microsoft/cheriot-rtos/blob/43861b3f4a7da7208ecb2824d39935555d832ba1/sdk/core/token_library/token_unseal.S#L54-L61
- the UART-based
debuglibrary loads a read-write capability through PCC: https://github.com/microsoft/cheriot-rtos/blob/43861b3f4a7da7208ecb2824d39935555d832ba1/sdk/lib/debug/debug.cc#L22-L25
In general, you're right that we almost always want to treat library functions as acting on (and, in particular, mutating) only data reachable through (suitably authorizing) argument capabilities. Most of the libraries in the CHERIoT SDK behave that way. But, in tension with that, sometimes we also want what might be called benign violations of this principle. (This might sound similar to benign side-effects in nominally functional languages.)
As an aside, the lack of compartment switching to and from libraries cuts both ways. The debug library additionally is not concerned with leaking "secrets" (the MMIO capability to the UART) to its caller, because that would expose no meaningful additional affordances to the caller, and so it can be written in C++. OTOH, the fast unsealer, like the switcher, must (at the moment) be carefully written assembler to ensure that secrets do not leak despite the lack of sanitization.
I think there's a strong case to be made that we don't want to be able to find MC+W-bearing capabilities through PCC, but that's not something we can easily enforce architecturally. Specifically, we can't make PCC weak or we'll break the UART example, and we don't have anything to strip MC (while iovec-like structures of pointers to flat buffers are likely common, "casting" something into that form that wasn't already seems kind of odd to want to do).
But, as often the case for things too hard for architecture, we can punt to higher levels of abstraction: IIRC, the linker report will attest to all capabilities constructed within the PCC region, and so the build system policies can ensure that libraries are not being shady.
vmurali
From my understanding, libraries work as follows: if one compartment calls a library function, it can rest assured that the data it sent the library cannot go outside the caps present in the passed arguments. If a second compartment calls the same library function again, the library function cannot access the old data passed by the first compartment unless the second compartment also passes in the necessary caps. The library relies on not having a read/write cap to global memory to ensure the above.
But, one can have a cap with read/write permissions inside the PCC region of a library that can be loaded by the library. This violates the above invariant, and the library can pass confidential data obtained from the first caller to the second caller. Is this behavior expected? If so, how are library calls not subject to the same sanitization as compartments, via the switcher? What is the expected use case of libraries?
Why is MC implicitly given to caps with EX permission? Is there any use case where you want to read caps from the PCC region? I can understand reading read-only data from the PCC region.