Position paper: Sapper -- a language for provable hardware policy enforcement

  • Authors:
  • Xun Li;Vineeth Kashyap;Jason K. Oberg;Mohit Tiwari;Vasanth Ram Rajarathinam;Ryan Kastner;Timothy Sherwood;Ben Hardekopf;Frederic T. Chong

  • Affiliations:
  • University of California, Santa Barbara, Santa Barbara, CA, USA;University of California, Santa Barbara, Santa Barbara, CA, USA;University of California, San Diego, La Jolla, CA, USA;University of California, Berkeley, Berkeley, CA, USA;University of California, Santa Barbara, Santa Barbara, CA, USA;University of California, San Diego, La Jolla, CA, USA;University of California, Santa Barbara, Santa Barbara, CA, USA;University of California, Santa Barbara, Santa Barbara, CA, USA;University of California, Santa Barbara, Santa Barbara, CA, USA

  • Venue:
  • Proceedings of the Eighth ACM SIGPLAN workshop on Programming languages and analysis for security
  • Year:
  • 2013

Quantified Score

Hi-index 0.00

Visualization

Abstract

We describe Sapper, a language for creating critical hardware components that have provably secure information flow. Most systems that enforce information flow policies place the hardware microarchitecture within the trusted computing base, and also assume that the observable behavior of that microarchitecture is fully and correctly documented. However, the reality is that this behavior is incompletely (and sometimes incorrectly) specified, and that the microarchitecture itself often contains implementation bugs. This fact means that all such systems are vulnerable to attack by exploiting undocumented or buggy hardware features. Sapper addresses this problem by enabling flexible and efficient hardware design that is provably secure with respect to a given information flow policy. Sapper uses a hybrid approach that leverages unique language features and static analysis to determine a set of dynamic checks that are automatically inserted into the hardware design. These checks are provably sufficient to guarantee that the resulting hardware prevents all explicit, implicit, and timing channels even if the hardware is otherwise buggy or poorly documented.