caprevoke should update aliasing mappings when marking a page capdirty

[markjdb]

Suppose a page is mapped multiple times into an address space. During revocation scans, there is a window between visits to the aliasing mappings of that page. During that window, it is possible for capabilities to be written to a unvisited alias, and loaded from the visited alias. The loads may not trap if the LCLG has already been updated, in which case capabilities escape the revoker.

A rough solution would consist of broadcasting the transition to capdirty to all PTEs, i.e., increment the LCLGs of aliases upon this state transition, ensuring that a subsequent load will be noticed by the revoker.

[nwf]

Belatedly, this is only a risk if aliases straddle address spaces or there is some other "leak" of a pointer around revocation. The intended invariant of Cornucopia Reloaded is

any valid capability in a user thread register file did not not in quarantine as of the last epoch start

A consequence is that any capability that can be written to a page('s alias) does not need to be revoked in the current epoch (but might or might not be revoked in this epoch's sweep if its target has subsequently been quarantined, such that it would need to be revoked in the next epoch).

In practice, cross-AS aliases and un-checked kernel hoards break that intent, but the former are rare and possibly obviated by collocated processes, and the latter are "just" bugs that need fixing.