Scribit Jonathan S. Shapiro dies 22/04/2006 hora 13:53: > > > couldn't S drop it's capability in a way that won't trigger the > > > send that the "invoke on delete" bit asks for? > > IIUC, that would enable a malicious S to let C be waiting > > indefinitely for the answer > It is not possible in principle to prevent this. Do the exercise: > design an S that achieves this denial even if "send on overwrite" is > present.
OK: S keeps the capability and just don't bother giving answer to the request... I was too focused on the case where we want to kill S when we find it is malicious (or buggy, FWIW). So what should C do to avoid memory leaks (he asks for something through a capability, providing the space for the answer, and never gets anything, probably several times) or freeze (when waiting for an answer to continue it's work). In some cases, I suppose human intervention is possible, like when a process waits for a device driver to perform (typically disk write) that cannot, but that's not suitable everywhere. There are many cases where we could expect the system to recover nicely by it's own. Are timeouts to be avoided most or all of the time? What are the alternatives? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
