Hello again, > NF> what do you mean by "full revoke of the range"? > NF> > NF> If a PD cap goes away, won't this implicitly revoke everything from > NF> the PD anyway? (including the not-yet-finished range of the preempted > NF> revoke operation) If so, this looks like a non-issue to me. Or does > NF> the preempted revoke happen to yield to leaking resources in any way? > > What I'm saying is... an operation that starts out as a directed revoke will > turn into a revoke on the entire subtree if the PD cap goes away while the > revoke operation is preempted. Simply because at the time the revoke is > restarted, the limitation "only this single PD" can no longer be applied.
it seems I slightly misunderstood your proposal. In your solution, the revoke CRD argument refers to the address space of the the caller, not the targeted PD, right? If so, your phrasing makes sense. But couldn't the revoke syscall take a CRD referring to the targeted PD as argument instead? Why the need to have the to-be-revoked range mapped in the caller's PD at all? Just in case you are worried about the preemption of a remote revocation in this case: This is no problem for Genode. A PD cap vanishes in core in the event of process destruction only. The corner case of an eventually occurring partial revocation will be taken care of by the destruction of the whole PD. Cheers Norman ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
