Submitted Abstract
In nearly all ICT platforms, the hypervisor, microkernel, or, more generally, the lowest-level operating-system kernel, form the last line of defense against intrusions by highly-skilled and well equipped adversarial teams. Once compromised, adversaries gain full access to all information and complete control over all platform resources, including, in the case of cyber-physical systems, extended control over the very physical environments on which these systems act (e.g., a nuclear power plant, a power grid station, or an autonomous car or drone). The root cause for this is that the operating-system kernel controls resource allocation and thereby how components are isolated from each other. It is as well irrelevant if this low-level kernel is implemented in software (as in traditional systems) or in firmware (as in Intel’s Secure Guard Extension), as shown by recently reported breaches, be it in Intel’s Management Engine, or about Spectre and Meltdown. Security incidents repeatedly remind us of how brittle our assumption of the ‘hypervisor as tamperproof and therefore unattackable’ is. In fact, once adversaries have penetrated this level, they have complete access over all system resources and all information stored therein. Even a formally verified kernel may fail, if there are model / reality discrepancies, or in the presence of hardware faults. In this project, we endorse the vision of fault and intrusion tolerance (a.k.a. Byzantine Fault Tolerance or BFT), applied to operating-system kernels. That is, through redundancy techniques, we make sure that the single point of failure that the latter prefigure today, is made to have a very low probability of failing. We overcome the generalized opinion that BFT techniques are too heavy and inefficient to be used at such low level, through the investigation of their implementation through hardware/operating-system co-design at the lowest kernel levels: (i) by adopting and extending existing intrusion tolerance mechanisms for use in tightly coupled VLSI settings (e.g., local replication across the tiles of a manycore system); and (ii) by investigating hardware support to allow kernel-level replicas to recover from intrusions. The second premise is especially relevant, since it must be ensured that no single kernel replica will have exclusive control over platform resources, but instead require consensus of a majority of other correct kernel replicas to utilize this power.