Hi Ben, (Please don't drop CC.) Glad I could help. Don't be too hard on yourself, hindsight is easy. For defensive programming reasons (which also makes attacks harder), it's good to have a non-zero guard for your caps which doesn't overlap with your virtual address space, at least for the first level. For the last level it depends on how you want overflows to behave: If you want to seamlessly continue into the next CNode, have a zero guard size (good for e.g. dynamic CNode allocation). If you want to detect overflow errors on sets of caps, make sure you have a guard size of at least 1 bit. Having a non-zero guard value has less advantage for later CNode levels. Greetings, Indan On 2024-11-15 16:25, Ben McCart wrote:

Indan,

Thank you so much!  seL4_CNode_Mint instead of seL4_CNode_Copy solved my problem.  The piece I was missing was that I needed to change the guard on the original seL4_CapInitThreadCNode when copying it into the first CSlot of the new root CNode.  (Doh!)   I should have caught that as you said explicitly in you prior response that each CNode capability can have different guard bits set.  (I just didn't think carefully enough about that.)

On 11/15/2024 4:55 AM, Indan Zupancic wrote:

...

seL4_CNode_Copy can't change the guard, you have to use seL4_CNode_Mint() if you need to change it:

assert(bi->initThreadCNodeSizeBits <= 16); seL4_CNode_Mint(      cspace_cap,      0,                                  // Destination index in the new Cap table.      16,                                // Number of bits for the new Cap table.      seL4_CapInitThreadCNode,      seL4_CapInitThreadCNode,      seL4_WordBits,      seL4_AllRights,      16 - bi->initThreadCNodeSizeBits); // Zero pad guard to reach 16 bits. <SNIP> Indan

-Ben