LMS-Verify: abstraction without regret for verified systems programming

Abstract

Performance critical software is almost always developed in C, as programmers do not trust high-level languages to deliver the same reliable performance. This is bad because low-level code in unsafe languages attracts security vulnerabilities and because development is far less productive, with PL advances mostly lost on programmers operating under tight performance constraints. Highlevel languages provide memory safety out of the box, but they are deemed too slow and unpredictable for serious system software. Recent years have seen a surge in staging and generative programming: the key idea is to use high-level languages and their abstraction power as glorified macro systems to compose code fragments in first-order, potentially domain-specific, intermediate languages, from which fast C can be emitted. But what about security? Since the end result is still C code, the safety guarantees of the high-level host language are lost. In this paper, we extend this generative approach to emit ACSL specifications along with C code. We demonstrate that staging achieves "abstraction without regret" for verification: we show how high-level programming models, in particular higher-order composable contracts from dynamic languages, can be used at generation time to compose and generate first-order specifications that can be statically checked by existing tools. We also show how type classes can automatically attach invariants to data types, reducing the need for repetitive manual annotations. We evaluate our system on several case studies that varyingly exercise verification of memory safety, overflow safety, and functional correctness. We feature an HTTP parser that is (1) fast (2) high-level: implemented using staged parser combinators (3) secure: with verified memory safety. This result is significant, as input parsing is a key attack vector, and vulnerabilities related to HTTP parsing have been documented in all widely-used web servers.

Verifying software network functions with no verification expertise

“…A key element that enables this is the level of abstraction of the NF spec and a technique to bridge the spec to the implementation. (2) We verify the entire software stack, reducing the trusted computing base (TCB) to the hardware, the Clang and GCC compilers, a small piece of OS startup code, and our verification toolchain. A key element that enables this is a domain-specific operating system we built and a mechanism that verifies just those parts of the stack that are required by the NF in question.…”

“…libVig also provides primitives for reading system time and parsing packet headers. With some further engineering, verified crypto primitives [51] and verified regexp parsing primitives [2] can be added to complete the library. As shown in §6.4, it is reasonable to expect that such an expanded version of libVig would be sufficient for building most NFs.…”

“…This is because, the less "primitive" a primitive is, the more likely it is to require changes in order to be useful to a new NF. Once we add verified crypto primitives from HACL* [51] and regexp primitives from LMS [2], libVig will have all the data structures needed to write all the 18 NFs. At that point, NF developers should be able to write any NF they wish in Vigor, push a button, and verify it all the way down to the hardware.…”

“…As a result, we cannot verify NFs that need such primitives, e.g., deep packet inspection or intrusion detection systems. We can fix this by incorporating into libVig verified open-source libraries like LMS [2] for regular expression matching and HACL* [51] for cryptographic primitives.…”