Was more fine-grained CNode access control ever considered?

seL4 kernel
1

Any capability to a CNode is sufficient to perform any CNode operations on the caps stored in slots in the CNode including deletions. Being able to prevent another entity from deleting or modifying caps in a CNode is something that would be useful for implementing hardened functions within an app that can be relied on to not have been modified by behavior elsewhere in the app.

Program code that performs seL4 invocations can already be made immutable with read-only executable memory and data, but this can be subverted if the caps that the code is trying to invoke have been modified. By being able to restrict modifying specific slots in a CNode, an OS is able to provide functionality similar to a vDSO that can be installed in each app and would allow for an app to jump execution to an address that it can trust to correctly execute. This would be useful for functionality such as self-checking operations.

I think the above functionality can currently be implemented by using a fault-handling thread that is more strongly isolated from the rest of the app but this has a larger runtime cost than a local function call and restricts what else the fault-handler thread can be used for.

Also, this mechanism would allow static components to be slightly more robust if they can’t accidentally delete all the caps in CNodes they have access to.

2

I think we did use to have read-only rights on CNode caps in the very beginning and removed them to make things simpler. Is that what you’re proposing to put back in?

That right would mean that you’d need write for operations that change the node, but there could be some operations (I’m not actually sure which, should check) that are still available for read-only. I guess invoking caps would be one of these.

(This would affect all slots in this CNode – specific slots or slot ranges would need space in the cap to encode, which probably gets more complex than we want).

3

Is that what you’re proposing to put back in?

Essentially. A way that allows a component loader to be able to lock a subset of the slots in the CSpace of a loadee. Currently any thread that can address a CNode cap can delete any caps inside it. My opinion is that this is authority that should be distinct from the authority to use a CNode in calls such as seL4_CNode_SaveCaller and seL4_CNode_CancelBadgedSends.

If you wish, I can add some concrete examples when I get a chance to write them up.

4

Maybe a small pre-RFC, yes. This would probably not be too hard to verify.