Rename Permit_CInvoke to Permit_Invoke.

This is more consistent with, for example, Permit_Seal gating use of CSeal. Co-authored-by: Jessica Clarke <[email protected]> Fixes #20
CTSRD-CHERI · Nov 1, 2022 · 9c24c5f · 9c24c5f
1 parent 6ba60fc
commit 9c24c5f
Show file tree

Hide file tree

Showing 5 changed files with 16 additions and 12 deletions.
diff --git a/app-cheri-128.tex b/app-cheri-128.tex
@@ -251,7 +251,7 @@ \subsection{Implementation}
 \cperms{}[5] & 5 & \cappermSC \\
 \cperms{}[6] & 6 & \cappermSLC \\
 \cperms{}[7] & 7 & \cappermSeal \\
-\cperms{}[8] & 8 & \cappermCInvoke \\
+\cperms{}[8] & 8 & \cappermInvoke \\
 \cperms{}[9] & 9 & \cappermUnseal \\
 \cperms{}[10] & 10 & \cappermASR \\
 \cuperms{}[15--18] & 11--14 & Software-defined permissions \\

diff --git a/app-experimental.tex b/app-experimental.tex
@@ -369,14 +369,14 @@ \section{Compressed Permission Representations} % <<<
 However, the notion of other spaces is not entirely out of the question; {\em
 physical} addresses may prove to be a compelling example on some systems.
 
-While \cappermCInvoke* is {\em checked} only as part of \insnref{CInvoke}'s
+While \cappermInvoke* is {\em checked} only as part of \insnref{CInvoke}'s
 operation on sealed (i.e., object) capabilities, it is inherited from these
 sealed capabilities' precursors.  That is, the present CHERI architecture
 permits the creation of regions of virtual address space that can be
 (subdivided and) sealed, but for which these derived object capabilities are
 not useful with \insnref{CInvoke} (just with \insnref{CUnseal}).
 The utility of such regions is perhaps not readily apparent, but any shift
-to make \cappermCInvoke* apply only to object capabilities would require
+to make \cappermInvoke* apply only to object capabilities would require
 modification of the \insnref{CSeal} instruction and would slightly
 change the capability ontology.
 
@@ -443,12 +443,12 @@ \subsection{A Worked Example of Type Segregation} % <<<
 the remaining seven bits correspond
 one-to-one with memory-specific permissions.  Specifically, they are:
 \cappermX* (Ex), \cappermL* (L), \cappermS* (St),
-\cappermLC* (LC), \cappermSC* (SC), \cappermCInvoke* (CC),%
+\cappermLC* (LC), \cappermSC* (SC), \cappermInvoke* (I),%
 %
 \footnote{While any capability type can, in principle, be sealed and could be
 unsealed at \insnref{CInvoke} time, \insnref{CInvoke} unseals only two
 capabilities, installing them as PCC and IDC.  As such, it seems sensible to
-restrict \insnref{CInvoke} to operating only on VA capabilities, and so \cappermCInvoke is
+restrict \insnref{CInvoke} to operating only on VA capabilities, and so \cappermInvoke is
 defined only therein.}
 %
 and \cappermASR* (ASR).  We have made no effort to

diff --git a/chap-architecture.tex b/chap-architecture.tex
@@ -404,7 +404,7 @@ \subsubsection{Permission Bits}
 5 & \cappermSC		& \checkmark	& Unsealed	& - \\
 6 & \cappermSLC		& \checkmark	& Unsealed	& - \\
 7 & \cappermSeal	& \checkmark	& Unsealed	& Object Type \\
-8 & \cappermCInvoke	& \checkmark	& Sealed	& - \\
+8 & \cappermInvoke	& \checkmark	& Sealed	& - \\
 9 & \cappermUnseal	& \checkmark	& Unsealed	& Object Type \\
 10 & \cappermASR	& \checkmark	& Unsealed	& - \\
 11 & \cappermCid	& \checkmark	& Unsealed	& CID \\
@@ -438,7 +438,7 @@ \subsubsection{Permission Bits}
 
 \item[\cappermSeal] Allow this capability to authorize the sealing of another capability with a \cotype{} equal to this capability's \cbase{} $+$ \coffset{}.
 
-\item[\cappermCInvoke] Allow this sealed capability to be used with \insnref{CInvoke}.
+\item[\cappermInvoke] Allow this sealed capability to be used with \insnref{CInvoke}.
 
 \item[\cappermUnseal] Allow this capability to be used to unseal another capability with a \cotype{} equal to this capability's \cbase{} $+$ \coffset{}.
 
@@ -646,7 +646,7 @@ \subsubsection{Pointer Values in Capabilities}
 \cappermSC, and code pointers, which may have enabled
 permissions that include \cappermL, \cappermX, and
 \cappermLC.
-Other permissions, such as \cappermG or \cappermCInvoke, may also be present.
+Other permissions, such as \cappermG or \cappermInvoke, may also be present.
 The following architectural values will normally be used:
 
 \begin{itemize}
@@ -2484,7 +2484,7 @@ \subsubsection{Capability Exception Causes}
 0x16 & \cappermSLC Violation \\
 0x17 & \cappermSeal Violation \\
 0x18 & \cappermASR Violation \\
-0x19 & \cappermCInvoke Violation \\
+0x19 & \cappermInvoke Violation \\
 0x1a & \emph{reserved} \\
 0x1b & \cappermUnseal Violation \\
 0x1c & \cappermCid Violation \\
@@ -2546,7 +2546,7 @@ \subsubsection{Capability Exception Priority}
 3  & Seal Violation \\
 4  & Type Violation \\
 5  & \cappermSeal Violation \\
-   & \cappermCInvoke Violation \\
+   & \cappermInvoke Violation \\
    & \cappermUnseal Violation \\
    & \cappermCid Violation \\
 6  & \cappermX Violation \\

diff --git a/glossary.tex b/glossary.tex
@@ -300,7 +300,7 @@
   non-monotonicity in the \gls{CHERI-RISC-V} and \gls{CHERI-x86-64} ISAs.
 \psnote{See Kyndylan's note for capability monotonicity}
   It can directly enter any userspace domain described by a pair
-  of sealed capabilities with the \emph{Permit\_CInvoke} permission set.
+  of sealed capabilities with the \emph{Permit\_Invoke} permission set.
   In particular, it can
   safely enter userspace domain-transition code
   described by the sealed \gls{code capability} while also unsealing

diff --git a/preamble.tex b/preamble.tex
@@ -380,7 +380,7 @@
 \makeatother
 \makecapperm{ASR}{Access\_System\_Registers}
 \makecapperm{Cid}{Set\_CID}
-\makecapperm{CInvoke}{CInvoke}
+\makecapperm{Invoke}{Invoke}
 \makecapperm{L}{Load}
 \makecapperm{LC}{Load\_Capability}
 \makecapperm{S}{Store}
@@ -391,6 +391,10 @@
 \makecapperm{X}{Execute}
 % No Permit_, so always use starred form even if not given
 \makecapperm*{G}{Global}
+\makeatletter
+% Legacy until Sail is updated for Perm_Invoke
+\ea\ea\ea\let\csname @capperm@\detokenize{Permit\_CInvoke}\ea\endcsname\csname @capperm@\detokenize{Permit\_Invoke}\endcsname
+\makeatother
 
 \makeatletter
 \newcommand{\@insnlabelname}[2]{insn:#1:#2}