Revoking Access after a Call

Capability patterns prescribe passing capabilities as parameters to a called function, (callee herein). Less often they prescribe revoking (or rescinding) those capabilities after the return from the callee. The capability in question is to the object herein. When should they prescribe revocation?

Generally it would be good to revoke after each call except for those cases where the agreed contract is for the callee to retain the capability for use subsequent to the call. Every capability system that I know imposes some extra cost to such revocation however and I consider here some situations where there is little or no advantage to revocation.

It is first necessary to try to enumerate the cases where the caller might be harmed by subsequent invocation to the capability. This enumeration may be incomplete.

The capability confers ‘read’ access to a mutable object and information written into the object, subsequent to the return must not be available to the callee. If the capability is to a portion of the caller’s address space and that space is reallocated to a different use after the call then the callee may be able to see secrets that it has no natural right to.
The capability confers ‘write’ access to a mutable object and the callee modifies the object subsequent to the return, contrary to the assumptions of the caller.
This attack is no worse than the callee making the harmful modification during the call, unless the caller is in a position to, and can afford to examine the object after revocation to ensure no harm has been done. This is an unusual situation, I think, because the caller usually lacks the knowledge, or even authority, to do so (because of abstraction). Also the cost may be prohibitive. The check may be omitted as a mere oversight.

In many situations it is possible to fabricate a narrower capability dynamically at the call site. In several languages I can write something such as

SmallTalk: callee([j, v | j<1000 ifTrue ob[j] <- v])
Algol68: callee((INT j, VAL v)VOID: IF j<1000 THEN on[j] := v FI)
Scheme: (callee (lambda (j v) (if (< j 1000) (vector-set! ob j v))))

In each case the capability to an anonymous procedure is passed to enable the callee to modify any of the first 1000 entries of array ob. In Keykos this was fairly easy to do but only by some one with detailed knowledge of the low-level assembly language mechanisms.

In some systems transient capabilities may exist which are produced by the call primitive and revoked by the return primitive, but such capabilities are another sort of animal; task switching must me somehow permitted to preserve these over scheduling events. Different sorts of capabilities are a large architectural expense. In the Algol68 case the procedure value passed is just such a transient value. For Scheme and Smalltalk the callee might retain the ability to modify ob after the return.