Formal verification of SSA-based optimizations for LLVM

Zhao, Jian-Zhou; Nagarakatte, Santosh; Martin, Milo M. K.; Zdancewic, Steve

doi:10.1145/2491956.2462164

Cited by 57 publications

(15 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As the compiler and the witness generator do not require formal verification, the size of the trusted code base shrinks substantially. Witnessing also requires much less effort than a full mathematical proof: as observed in [19], a mathematical correctness proof of SSA (Static Single Assignment) conversion in Coq is about 10,000 lines [29], while refinement checking can be implemented in around 1,500 lines of code, most of which comprises a witness validator which can be reused across different transformations. Our work shows how to extend this concept, originally developed for correctness checking, to the preservation of a large class of security properties, with the following important distinction.…”

Section: Discussion and Related Workmentioning

confidence: 99%

Witnessing Secure Compilation

Namjoshi

Tabajara

2020

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Compiler optimizations are designed to improve run-time performance while preserving input-output behavior. Correctness in this sense does not necessarily preserve security: it is known that standard optimizations may break or weaken security properties that hold of the source program. This work develops a translation validation method for secure compilation. Security (hyper-)properties are expressed using automata operating over a bundle of program traces. A flexible, automatonbased refinement scheme, generalizing existing refinement methods, guarantees that the associated security property is preserved by a program transformation. In practice, the refinement relations ("security witnesses") can be generated during compilation and validated independently with a refinement checker. This process is illustrated for common optimizations. Crucially, it is not necessary to verify the compiler implementation itself, which is infeasible in practice for production compilers.

show abstract

Section: Discussion and Related Workmentioning

confidence: 99%

Witnessing Secure Compilation

Namjoshi

Tabajara

2020

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…We conjecture that our reinterpretation techniques can be generalized to most passes of CompCert down to assembly. While we leave such generalization as future work, some guarantees from C to assembly can be derived by instrumenting CompCert [Barthe et al 2014] and LLVM [Almeida et al 2016b;Zhao et al 2012Zhao et al , 2013 and turning them into certifying (rather than certified) compilers where security guarantees are statically rechecked on the compiled code through translation validation, thus re-establishing them independently of source-level security proofs. In this case, rather than being fully preserved down to the compiled code, Low * -level proofs are still useful to practically reduce the risk of failures in translation validation.…”

Section: From C * To Compcert Clight and Beyondmentioning

confidence: 99%

Verified low-level programming embedded in F*

Protzenko

Zinzindohoué

Rastogi

et al. 2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

We present Low * , a language for low-level programming and verification, and its application to high-assurance optimized cryptographic libraries. Low * is a shallow embedding of a small, sequential, well-behaved subset of C in F * , a dependently-typed variant of ML aimed at program verification. Departing from ML, Low * does not involve any garbage collection or implicit heap allocation; instead, it has a structured memory model à la CompCert, and it provides the control required for writing efficient low-level security-critical code. By virtue of typing, any Low * program is memory safe. In addition, the programmer can make full use of the verification power of F * to write high-level specifications and verify the functional correctness of Low * code using a combination of SMT automation and sophisticated manual proofs. At extraction time, specifications and proofs are erased, and the remaining code enjoys a predictable translation to C. We prove that this translation preserves semantics and side-channel resistance. We provide a new compiler back-end from Low * to C and, to evaluate our approach, we implement and verify various cryptographic algorithms, constructions, and tools for a total of about 28,000 lines of code, specification and proof. We show that our Low * code delivers performance competitive with existing (unverified) C cryptographic libraries, suggesting our approach may be applicable to larger-scale low-level software.

show abstract

“…Compiler correctness. A compiler can be written in a mathematical theorem prover (e.g., CompCert [27], Vellvm [52,53]), which would require one to figure out the specification in such a setting [37,49]. Alternatively, various other DSLs have also been proposed for compiler construction [23,26].…”

Section: Related Workmentioning

confidence: 99%

Alive-Infer: data-driven precondition inference for peephole optimizations in LLVM

Menendez

Nagarakatte

2017

Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation

Self Cite

View full text Add to dashboard Cite

Peephole optimizations are a common source of compiler bugs. Compiler developers typically transform an incorrect peephole optimization into a valid one by strengthening the precondition. This process is challenging and tedious. This paper proposes ALIVE-INFER, a data-driven approach that infers preconditions for peephole optimizations expressed in Alive. ALIVE-INFER generates positive and negative examples for an optimization, enumerates predicates on-demand, and learns a set of predicates that separate the positive and negative examples. ALIVE-INFER repeats this process until it finds a precondition that ensures the validity of the optimization. ALIVE-INFER reports both a weakest precondition and a set of succinct partial preconditions to the developer. Our prototype generates preconditions that are weaker than LLVM's preconditions for 73 optimizations in the Alive suite. We also demonstrate the applicability of this technique to generalize 54 optimization patterns generated by Souper, an LLVM IR-based superoptimizer.

show abstract

Formal verification of SSA-based optimizations for LLVM

Cited by 57 publications

References 19 publications

Witnessing Secure Compilation

Witnessing Secure Compilation

Verified low-level programming embedded in F*

Alive-Infer: data-driven precondition inference for peephole optimizations in LLVM

Contact Info

Product

Resources

About