On 2016-10-30 20:36, [email protected] wrote: > Hey Corey. > > So, long story, what were you planning on doing with badge cancellation > in Robigalia? >
It's somewhat complicated to explain, and I haven't finished writing it up. Furthermore, these are just ideas right now, we haven't actually fully implemented it yet (though we've started on a few prototypes). I'll do my best to explain. In Robigalia, a badge corresponds 1-1 to a region of a process's vspace, which is the state for whatever methods exposed by the process. The backing storage for that region is borrowed from clients, which can revoke it at any point (and the process can of course also decide to destroy the region). If at some point the process is servicing a request and encounters a fault, the object that the request was to is dropped on the floor and the region is unmapped by the fault handler. To ensure that the badge (and thus the corresponding vspace region) can be re-used (to prevent resource exhaustion etc), the process is responsible for revoking all access via that badge. This prevents threads from exceeding their intended authority when a new object is created using that badge. I admit I don't fully understand the implications of Recycle here, or what the exact derivation subtree would look like in our usecase. For example, here's an example of object creation: seL4_CNode_Mint(my_cspace, my_root_ep_idx, my_root_ep_depth, some_free_slot_root, some_free_slot_index, some_free_slot_depth, AllRights, some_free_badge); seL4_CNode_Copy // map some space at the corresponding vaddr // setup initial state // setup IPC to transfer the newly minted cap seL4_ReplyRecv(...) Later when the object is to be destroyed, the hypothetical sequence of operations is: seL4_CNode_Recycle(my_cnode, some_free_slot_index, some_free_slot_depth) // unmap region > 1: OK, short version, a multi-user server can keep a spare thread > around, revoke some badges, and then queue the thread in the endpoint as > a sentinel, with a message saying "you may now reuse the revoked badges". > These seems like it should work just as well for our purposes, although I'm a bit worried about timeliness of reusing the badge. I guess I'd have to add some sort of tombstone state for that badge while it's waiting for the queue to drain. Best, -- cmr http://octayn.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
