A theory of platform-dependent low-level software

Abstract

The C language definition leaves the sizes and layouts of types partially unspecified. When a C program makes assumptions about type layout, its semantics is defined only on platforms (C compilers and the underlying hardware) on which those assumptions hold. Previous work on formalizing C-like languages has ignored this issue, either by assuming that programs do not make such assumptions or by assuming that all valid programs target only one platform. In the latter case, the platform's choices are hard-wired in the language semantics.In this paper, we present a practically-motivated model for a C-like language in which the memory layouts of types are left largely unspecified. The dynamic semantics is parameterized by a platform's layout policy and makes manifest the consequence of platform-dependent (i.e., unspecified) steps. A type-and-effect system produces a layout constraint: a logic formula encoding layout conditions under which the program is memory-safe. We prove that if a program type-checks, it is memory-safe on all platforms satisfying its constraint.Based on our theory, we have implemented a tool that discovers unportable layout assumptions in C programs. Our approach should generalize to other kinds of platform-dependent assumptions.

A theory of platform-dependent low-level software

“…For example, it supports the platformdependent idiom of treating an array of: struct { short i1; short i2; short i3; short i4;}; as an array of short. We have proven safety given this subtyping rule (Nita et al 2007). …”

“…See the technical report (Nita et al 2007) for the complete system, which includes rules for run-time forms (such as w) and heaps.…”

“…Additional discussion of extensions, including support for readonly (const) pointers, for platforms that choose to skip pad bytes when copying values, and for proper recursive subtyping (Amadio and Cardelli 1993), can be found in the companion technical report (Nita et al 2007). All these extensions permit more subtyping.…”

Executable formal semantics for the POSIX shell

“…We can also imagine implementing a read-only filesystem that allows access to the real, underlying filesystem, but treats writes (and other dangerous operations, like execve) as noops. We consider platform-specific filesystems, like /proc, as out of scope; we could in theory apply platform-dependent reasoning [Nita et al 2008].…”

An executable formal semantics of C with applications

“…This means we cannot catch undefined behavior related to alignment restrictions. Note that others have worked on formalizing alignment requirements [20], but it has never been incorporated into a full semantics for C. We also do not handle type qualifiers (like const or volatile); we simply ignore them. This is safe to do when interpreting correct programs, but it means we are not detecting problems related to those features in incorrect programs.…”