Umodified signal handling:
When a signal must be delivered to the target thread and the code is executing in a sandbox of that thread. Then sandbox code’s stack cannot be used for signal handling. Kernel will have different operations in the following situations 1:
Automatic trusted-stack unwinding using cheri_stack_unwind, returning control to the caller. Assumptions:
SIGPROP_SBUNWINDIn this case, ‘sandboxed code’ means that one or more frames are present on the trusted stack, rather than that the current execution context lacks privilege.
If handler registered, then we must install a suitable signal-handling context (typically, ambient authority).
However, we cannot trust the stack in the sandbox context, thus we will instead use the UNIX alternative signal stack.
If one is not defined for the thread, the process will be terminated as there is no safe way to handle the signal.
In this case and the following case, ‘sandboxed code’ means that the current executing context does not have ambient authority – i.e., that it cannot invoke system calls.
If an alternative signal stack is configured, then ambient authority will be temporarily restored and signal delivery will take place no the alternative stack.
Currently, the kernel installs ambient-authority capabilities in PCC, C0, C11 (stack capability), and IDC prior to executing the signal handler.
When signal handler returns, the kernel will restore capability-register state saved on the stack. This will release ambient authority if the saved (and possibly rewritten) register does not hold it.
Configuring an alternative signal stack requires that a signal stack be allocated and registered with signalstack and the signal handler be registered to use it with the SA_ONSTACK flag in sigaction1.
Up to 2015, programmer’s guide:
User code can access the saved capability-coprocessor register values, including the capability-cause register (cf_capcause), via a struct cheriframe pointed to by the uc_mcontext.mc_cp2state pointer in the context_t argument to the signal handler.
The signal handler should check that the mc_cp2state pointer is non-NULL, and the correponding uc_mcontext.mc_cp2state_len field is equal to sizeof(struct cheriframe), before proceeding.
This ABI is currently immature, as the same daa structure is used both for kernel’s internal representation of the capability and its on-stack representation; this will change in the future version of CheriBSD.
As ambient authority is installed, signal handlers are also able to rewrite the trusted stack1. This allows more mature handling of exceptions within sandboxes or other invoked contexts – for example, unwinding of the trusted stack, garbage collection activitites, etc. In CheriBSD’s cheritest tool, this is used to handle timeouts trigged by SIGALRM, terminating sandboxed if they overrun their execution-time limit, for example.
A key design choice is that signal handlers are not invoked by a CCall-like mechanism. This is done for several reasons, not least that we wish to be able to handle trusted-stack overflow in userspace via a signal handler. Great care must be exercised in writing signal handlers that execute with ambient authority in order to not leak privileges to a non-ambient context2.
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?