Taming undefined behavior in LLVM

Lee, Jun-Young; Kim, Yoonseung; Song, Youngju; Hur, Chung-Kil; Das, Sanjoy; Majnemer, David; Regehr, John; Lopes, Nuno P.

doi:10.1145/3062341.3062343

Cited by 32 publications

(29 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In our handling of uninitialized memory, we follow Lee et al [2017]. Upon allocation, memory holds a poison value that will cause the program to get stuck if it is ever used for a computation or a conditional branch.…”

Section: The Operational Semanticsmentioning

confidence: 99%

RustBelt: securing the foundations of the Rust programming language

Jung

Jourdan

Krebbers

et al. 2017

Proc. ACM Program. Lang.

241

170

View full text Add to dashboard Cite

Rust is a new systems programming language that promises to overcome the seemingly fundamental tradeoff between high-level safety guarantees and low-level control over resource management. Unfortunately, none of Rust's safety claims have been formally proven, and there is good reason to question whether they actually hold. Specifically, Rust employs a strong, ownership-based type system, but then extends the expressive power of this core type system through libraries that internally use unsafe features. In this paper, we give the first formal (and machine-checked) safety proof for a language representing a realistic subset of Rust. Our proof is extensible in the sense that, for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy in order for it to be deemed a safe extension to the language. We have carried out this verification for some of the most important libraries that are used throughout the Rust ecosystem.

show abstract

Section: The Operational Semanticsmentioning

confidence: 99%

RustBelt: securing the foundations of the Rust programming language

Jung

Jourdan

Krebbers

et al. 2017

Proc. ACM Program. Lang.

241

170

View full text Add to dashboard Cite

show abstract

“…In the presence of potential undefined behavior, compilers are allowed to assume that the program will never reach the conditions under which this undefined behavior is triggered. The compiler can then generate optimized program code based on this assumption [22]. Consequently, the compiler does not have to statically verify that the program is free of potential undefined behavior, and the compiler does not need to generate code that is capable of recognizing and mitigating undefined behavior.…”

Section: E Other Vulnerabilitiesmentioning

confidence: 99%

SoK: Sanitizing for Security

Song

Lettner

Rajasekaran

et al. 2019

2019 IEEE Symposium on Security and Privacy (SP)

View full text Add to dashboard Cite

The C and C ++ programming languages are notoriously insecure yet remain indispensable. Developers therefore resort to a multi-pronged approach to find security issues before adversaries. These include manual, static, and dynamic program analysis. Dynamic bug finding tools-henceforth "sanitizers"can find bugs that elude other types of analysis because they observe the actual execution of a program, and can therefore directly observe incorrect program behavior as it happens.A vast number of sanitizers have been prototyped by academics and refined by practitioners. We provide a systematic overview of sanitizers with an emphasis on their role in finding security issues. Specifically, we taxonomize the available tools and the security vulnerabilities they cover, describe their performance and compatibility properties, and highlight various trade-offs. class Base { virtual void func(); }; class Derived : public Base { public: int extra; }; Base b[2]; Derived * d = static_cast(&b[0]); // Bad-casting d->extra = ...; // Type-unsafe, out-of-bounds access, which // overwrites the vtable pointer of b[1]Listing 4. Bad-casting vulnerability leading to a type-and memory-unsafe memory access

show abstract

“…The most closely related work on the memory object model side is that of Kang et al [2015]; Lee et al [2018Lee et al [ , 2017. These study the complementary problem of the semantics for the LLVM intermediate language, focussed on the semantics implicitly assumed by compiler optimisations.…”

Section: Interacting With Iso Wg14 and Other Bodiesmentioning

confidence: 99%

Exploring C semantics and pointer provenance

Memarian

Gomes

Davis

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

The semantics of pointers and memory objects in C has been a vexed question for many years. C values cannot be treated as either purely abstract or purely concrete entities: the language exposes their representations, but compiler optimisations rely on analyses that reason about provenance and initialisation status, not just runtime representations. The ISO WG14 standard leaves much of this unclear, and in some respects differs with de facto standard usage Ð which itself is difficult to investigate.In this paper we explore the possible source-language semantics for memory objects and pointers, in ISO C and in C as it is used and implemented in practice, focussing especially on pointer provenance. We aim to, as far as possible, reconcile the ISO C standard, mainstream compiler behaviour, and the semantics relied on by the corpus of existing C code. We present two coherent proposals, tracking provenance via integers and not; both address many design questions. We highlight some pros and cons and open questions, and illustrate the discussion with a library of test cases. We make our semantics executable as a test oracle, integrating it with the Cerberus semantics for much of the rest of C, which we have made substantially more complete and robust, and equipped with a web-interface GUI. This allows us to experimentally assess our proposals on those test cases. To assess their viability with respect to larger bodies of C code, we analyse the changes required and the resulting behaviour for a port of FreeBSD to CHERI, a research architecture supporting hardware capabilities, which (roughly speaking) traps on the memory safety violations which our proposals deem undefined behaviour. We also develop a new runtime instrumentation tool to detect possible provenance violations in normal C code, and apply it to some of the SPEC benchmarks. We compare our proposal with a source-language variant of the twin-allocation LLVM semantics proposal of Lee et al. Finally, we describe ongoing interactions with WG14, exploring how our proposals could be incorporated into the ISO standard.

show abstract

Taming undefined behavior in LLVM

Cited by 32 publications

References 20 publications

RustBelt: securing the foundations of the Rust programming language

RustBelt: securing the foundations of the Rust programming language

SoK: Sanitizing for Security

Exploring C semantics and pointer provenance

Contact Info

Product

Resources

About