I have a question about the way that derived capabilities are handled in seL4.  
I'm posting here in the hope that somebody might be able to share some insights 
about this part of the design.

As I understand it, early versions of seL4's Mint operation allowed multiple 
derived levels of capabilities. (I'm thinking, in particular, of the 
description of Capability Derivation Trees, or CDTs, on Pages 36-38 of Dhammika 
Elkaduwe's thesis.) This, for example, would make it possible to construct a 
system with multiple threads, A, B, and C, each holding a capability to the 
same object where the capability in C is a CDT child of the capability in B, 
which in turn is a CDT child of the capability in A.  In this scenario, B would 
have authority to revoke the capability in C, including any further CDT 
children that C had created, but it wouldn't typically have authority over 
other children of the original capability in A.

So far as I can tell, this is not possible in the current version of seL4.  
Specifically, the reference manual (API version 1.3, Page 11) indicates that 
"Ordinary original capabilities can have one level of derived capabilities" and 
that "Further copies of these derived capabilities will create siblings".  In 
the scenario above, this suggests that the capabilities in B and C would be 
siblings and that there would be no easy way for B to track any additional 
sibling copies that C might have created.

Can someone provide background about why this change was made? I've seen that 
Dhammika had a working implementation of the original design, and although it 
was still technically limited to 128 levels, this was not found to be an issue 
in practice. But perhaps there were security concerns or problems with 
verification? Or maybe people who worked with the original system found that it 
wasn't useful in practice, or that it was hard to use effectively? Or maybe 
I've just misunderstood some aspect of the above?

Thanks and best wishes,
Mark


_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel

Reply via email to