C64-Secure ABI demo.

.buildbot.sh

@@ -12,7 +12,7 @@ echo "Checking clang-format..."
 CLANG_FORMAT=$CHERI_DIR/morello-sdk/bin/clang-format
 find . -iname "*.c" -o -iname "*.h" -o -iname "*.cpp" -o -iname "*.hpp" | xargs "$CLANG_FORMAT" --dry-run -Werror
 
-echo "Checking that all the purecap examples build for all platforms..."
+echo "Checking that all examples build for all platforms..."
 PLATFORMS='riscv64-purecap morello-purecap'
 # TODO: Add "example_allocators".
 for dir in . employee shared_objects timsort; do
@@ -24,7 +24,7 @@ for dir in . employee shared_objects timsort; do
     popd
 done
 
-echo "Checking that all the hybrid examples build on Morello..."
+echo "Checking that all the Morello hybrid examples build..."
 platform='morello-hybrid'
 for dir in hybrid hybrid/ddc_compartment_switching syscall-restrict; do
     pushd "$dir"
@@ -33,6 +33,15 @@ for dir in hybrid hybrid/ddc_compartment_switching syscall-restrict; do
     popd
 done
 
+echo "Checking that all the Morello purecap examples build..."
+platform='morello-purecap'
+for dir in morello-c64-secure; do
+    pushd "$dir"
+    make -f Makefile.$platform clean
+    make -f Makefile.$platform all
+    popd
+done
+
 export SSHPORT=10021
 
 echo "Running tests for 'riscv64-purecap' using QEMU."

morello-c64-secure/Makefile.morello-purecap

@@ -0,0 +1,11 @@
+# Copyright (c) 2024 The CapableVMs "CHERI Examples" Contributors.
+# SPDX-License-Identifier: MIT OR Apache-2.0
+
+include ../build/Makefile.vars.morello-purecap
+include ../build/Makefile.vars.common
+
+SHARED_SOURCES := impls.s
+RUNDIR := c64-secure
+export
+
+include ../build/Makefile.simple

morello-c64-secure/README.md

@@ -0,0 +1,73 @@
+# Morello C64-Secure Example
+
+This example demonstrates a few procedure-call standard variants that provide
+partial compartmentalisation with minimal cost.
+
+Full compartmentalisation usually requires register banking and explicit
+management of capabilities over the trust boundary. Often, an intermediary is
+required, such as a compartment manager. Such approaches have inherent code-size
+and performance costs, and so a cheaper (but imperfect) alternative might be
+preferred for routine function calls.
+
+For routine function calls, we consider the case where callee is not
+deliberately malicious, but might be susceptible to data-driven attacks. Such
+attacks should not have arbitrary access to the frame record (which could be
+used to divert control flow), nor to the caller's stack.
+
+Three ABIs, with this goal, are demonstrated:
+
+  A: "C64-Secure" (naive variant)
+
+    Restrict csp to the stack frame, and cfp to the frame record itself. Both
+    capabilities must be saved (alongside clr), so the frame record has three
+    entries in this variant.
+
+    This is a weak compartment because it relies on the generated code not
+    accessing cfp at all, other than in the function prologue and epilogue. This
+    can often be guaranteed, but not always.
+
+    This variant is simple, but its security is limited by the representable
+    precision. If the stack bounds are large (as they typically are), the
+    callee's stack will typically end up covering the whole stack anyway, since
+    `scbnds` is used, rather than `scbndse`. However, this variant could be
+    effective on threads or other subsystems with small stacks.
+
+    In the interactive demo: the bounds on csp don't actually appear to be
+    restricted unless you request very large stack frames.
+
+  B: "C64-Secure" (conservative variant)
+
+    As A, but pad stack frames to ensure that they don't overlap. This
+    guarantees the expected security proprties, but wastes a lot of space at the
+    start of the stack.
+
+    In the interactive demo: the bounds are precise, as expected, and csp never
+    grants access to the frame record, but there are a large number of (padding)
+    locals on each stack frame.
+
+  C: "C64-Secure v2"
+
+    Attempt to get the security properties of B, but with no wasted space.
+
+    - Leave cfp unrestricted (spanning the whole stack).
+    - Restrict csp to the current function's stack frame only.
+
+    Restricting csp to only a single function's frame (rather than all of the
+    remaining stack space) means that it can be much more precisely bounded.
+    In the function prologue, a new csp is derived from the caller's cfp.
+
+    As a bonus, only a two-entry stack frame is required. One slot holds clr (as
+    usual), and the other holds the caller's csp bounds and the cfp address.
+
+    A disadvantage of this variant is that more code is required, but this could
+    be simplified if frame sizes are known to be small. The example makes a
+    couple of simplifying assumptions (described in the code).
+
+  Z: "AAPCS64-cap"
+
+   This is the procedure-call standard used by C code compiled for Morello
+   purecap. It is provided here for reference.
+
+It is not easy to call between some of these variants, so the example won't
+provide all options. In practice, it would be possible to convert using a
+trampoline of some sort, but that isn't implemented here.