As discussed in the motivation for the ERC AdG ELVER, computer systems have become critical to modern society, but they are pervasively subject to security flaws and malicious attacks, with large-scale exposures of confidential data, denial-of-service, and ransom attacks, by well-resourced criminal groups and by major nation-state attackers.
An important root cause for this is the fact that conventional software engineering relies on non-mathematical test-and-debug development and prose specification. These have worked well
enough for the industry to thrive, but it builds systems that cannot be properly understood or reasoned about with such
methods: conventional testing can exercise common cases, and it is successfully used to build systems that _usually_ work, but to prevent security flaws, one needs them to be robust _in all cases_, to resist adversarial attackers who will seek out inputs that trigger what might be subtle single-line flaws in large codebases.
This is exacerbated by the (perhaps surprising disturbing) fact that the underlying hardware abstractions have not previously been well-defined -- the historical prose specifications have left important questions open, especially for their relaxed concurrency behaviour and its interaction with systems aspects such as virtual memory.
Security flaws are especially important for the major pan-industry components of our information infrastructure: processors, programming languages, security protocols, browsers, operating systems, hypervisors, and suchlike, as these are what are used to enforce security boundaries between the application programs built above them.
For example, hypervisors and operating systems use the virtual memory facilities provided by the underlying hardware architecture (such as Arm-A or x86) to enforce protection between virtual machines and processes running on the same system, by ensuring that they cannot accesses each others' memory without explicit permission, even if some virtual machines or processes have been subverted by an attacker.
But flaws in the operating system or hypervisor code could permit an attacker to work around such protection, and thereby to escalate an attack to take over an entire system.
Modern attacks typically exploit the combination of several errors and have become very sophisticated, hitting parts of the system that require great care to protect.
Our infrastructure is partitioned into a small number of monocultures, relying on a small number of operating systems and hypervisors, such as Android (based on the Linux kernel operating system) and iOS, for Android and Apple mobile phones, and those used by each major Cloud provider (Amazon, Google, Microsoft, etc.) to protect their own infrastructure and client virtual machines from each other.
Because of this, and because attacks can be automated, the potential impact of such an attack is enormous.
There is thus a very strong incentive to improve the engineering of such critical systems software. Ideally, one would _mathematically prove_ that it has the intended security properties -- proof, unlike testing, can check all possible execution paths for all possible inputs.
However, it is also undeniably (and unsurprisingly) a longer-term challenge than the conventional Linux-kernel software development process being used to build pKVM. Fortunately, ELVER has also laid the groundwork for various methods that build on our mathematical understanding of the Arm-A systems architecture to support _lighter-weight_ assurance boosting activities, to find subtle errors outside the domain of previous software verification and validation techniques.
**The technical problem addressed by ELVER-CHECK** is to discover, prototype, assess, and demonstrate how one can best use mathematical models of systems architecture to support conventional development of critical systems software, to increase assurance that it provides the intended security, at substantially lower cost than full verification.
The project thus addresses an important aspect of the societal problem of the pervasive insecurity of our critical software infrastructure.
There are various disciplines that such software has to follow when managing the underlying hardware mechanisms to correctly enforce protection. Conventional testing cannot check these, but building on our models, we can develop methods that can. This will provide substantially increased (but not total) assurance at relatively low cost, contrasting with the high assurance, but high cost and high research challenge, of full proof.
