Forbid S-mode execution from user memory

1 files changed, 25 insertions, 4 deletions

diff --git a/src/supervisor.tex b/src/supervisor.tex
index dfcfa85..6f70b67 100644
--- a/src/supervisor.tex
+++ b/src/supervisor.tex
@@ -207,11 +207,12 @@ either readable or executable (R=1 or X=1) will succeed.  MXR has no effect
 when page-based virtual memory is not in effect.
 
 The SUM (permit Supervisor User Memory access) bit modifies the privilege with
-which S-mode loads, stores, and instruction fetches access virtual memory.
+which S-mode loads and stores access virtual memory.
 When SUM=0, S-mode memory accesses to pages that are accessible by U-mode (U=1
-in Figure~\ref{sv32pte}) will fault.  When SUM=1, these accesses are
-permitted.  SUM has no effect when page-based virtual memory is not in effect,
-nor when executing in U-mode.
+in Figure~\ref{sv32pte}) will fault.  When SUM=1, these accesses are permitted.
+SUM has no effect when page-based virtual memory is not in effect, nor when
+executing in U-mode.  Note that S-mode can never execute instructions from user
+memory, regardless of the state of SUM.
 
 \begin{commentary}
 The SUM mechanism prevents supervisor software from inadvertently accessing
@@ -219,6 +220,26 @@ user memory.  Operating systems can execute the majority of code with SUM clear;
 the few code segments that should access user memory can temporarily set
 SUM.
 \end{commentary}
+\begin{commentary}
+The SUM mechanism permits S-mode software to access user data, but never to
+execute instructions from user memory.  Legitimate uses cases for execution from
+user memory in supervisor context are extremely rare in general and non-existent
+in POSIX-like environments.  However, bugs in supervisors that lead to arbitrary
+code execution are much easier to exploit if the supervisor exploit code can be
+stored in a user buffer at a virtual address chosen by an attacker.
+
+Some, non-POSIX, single address space operating systems do allow certain
+privileged software to partially execute in supervisor mode, while most programs
+run in user mode, all in a shared address space.  This use case can be provided
+using ``shadow mappings'' that alias such privileged modules into supervisor
+memory and kernel support for thunking privileged calls into the shadow mappings
+upon an instruction-fetch page fault.
+
+Aliases are not restricted and the same physical page may be visible as both
+supervisor and user pages at different virtual addresses.  The supervisor is
+responsible for the prevention or management of such aliases in accordance with
+its own policy.
+\end{commentary}
 
 \subsection{Supervisor Trap Vector Base Address Register ({\tt stvec})}