Why do we need automation for context switching?

Context switching looks like a bookkeeping task: save the old execution context, restore the next one, and continue. The security reality is sharper. If privileged software forgets a register or mishandles a piece of architectural state, information can cross a boundary it was never meant to cross.

The difficulty comes from the shape of modern ISAs. The relevant state is not described in one clean checklist. Details about one register may be split across instruction semantics, privilege-mode text, extension chapters, and informal notes. Some instructions update state only under particular conditions, and those conditions can depend on other state.

That is why automation matters. A human reviewer can understand the threat model, but asking humans to enumerate every possible state-changing instruction path is brittle. Sailor starts from machine-readable Sail specifications, uses Isla to explore instruction behavior, and applies an algorithm to identify the ISA state that must be swapped during context switches.

The complications are not abstract. Sailor was used to assess regular process context switching in the RISC-V Linux kernel and enclave context switching in Keystone and Komodo. In these settings, context switching is part of the security boundary, so a small omission can become an attack surface for unprivileged code.