Memory Safety Without Runtime Checks Or Garbage Collection *

Memory Safety Without Runtime Checks Or Garbage Collection *

Memory Safety Without Runtime Checks or Garbage Collection ∗ Dinakar Dhurjati Sumant Kowshik Vikram Adve Chris Lattner University of Illinois at Urbana-Champaign {dhurjati,kowshik,vadve,lattner}@cs.uiuc.edu ABSTRACT Keywords Traditional approaches to enforcing memory safety of pro- Embedded systems, compilers, programming languages, static grams rely heavily on runtime checks of memory accesses analysis, security, region management, automatic pool allo- and on garbage collection, both of which are unattractive for cation. embedded applications. The long-term goal of our work is to enable 100% static enforcement of memory safety for em- bedded programs through advanced compiler techniques and 1. INTRODUCTION minimal semantic restrictions on programs. The key result Current and future embedded systems demand increas- of this paper is a compiler technique that ensures memory ing software flexibility, including the ability to upgrade or safety of dynamically allocated memory without program- introduce software modules into existing applications both mer annotations, runtime checks, or garbage collection,and offline and during active operation. Such software upgrades works for a large subclass of type-safe C programs. The are becoming increasingly common for small consumer de- technique is based on a fully automatic pool allocation (i.e., vices, and are expected to be important even for more con- region-inference) algorithm for C programs we developed strained systems such as embedded control systems [23, 24] previously, and it ensures safety of dynamically allocated and sensor networks [20]. One of the key requirements for memory while retaining explicit deallocation of individual enabling dynamic software upgrades is to ensure that new objects within regions (to avoid garbage collection). For a software modules or applications do not compromise the safe diverse set of embedded C programs (and using a previous and correct functioning of an embedded device. One part technique to avoid null pointer checks), we show that we are of this problem is ensuring the memory safety of embedded able to statically ensure the safety of pointer and dynamic software, i.e., to guarantee that an upgraded software mod- memory usage in all these programs. We also describe some ule cannot corrupt the code or data of its host application. improvements over our previous work in static checking of (The term “memory safety” is defined in Section 2.) array accesses. Overall, we achieve 100% static enforcement Unfortunately, it appears that current language or system of memory safety without new language syntax for a signif- approaches for ensuring memory safety require significant icant subclass of embedded C programs, and the subclass is overheads in terms of runtime checks and garbage collec- much broader if array bounds checks are ignored. tion. Safe languages like Java [10], Modula-3, ML, Safe- C [1], Cyclone [13] and CCured [22] use a variety of runtime Categories and Subject Descriptors checks before individual memory operations such as bounds checks for array references, null pointer references, and type C.3 [Computer Systems Organization]: Special-Purpose conversions, and they rely on garbage collection to ensure and Application-based Systems; D.3 [Software]: Program- the safety of references to dynamically allocated memory. ming Languages; D.4.6 [Software]: Operating Systems— The overheads of runtime checking are quite significant: lan- Security and Protection guages like SafeC, CCured, Cyclone and Vault have reported slowdowns ranging from 20% up to 3x for different applica- General Terms tions [1, 22, 11, 7]. Many types of embedded software must operate under Security, Languages stringent energy, memory, and processing power limitations, and often under hard or soft real-time constraints as well. ∗ This has been sponsored by the NSF Embedded Systems The runtime overheads of safety checks and both the over- program under award CCR-02-09202 and in part by an NSF heads and the potential unpredictability of garbage collec- CAREER award, EIA-0093426 and ONR, N0004-02-0102. tion are unattractive for such software [4]. Permission to make digital or hard copies of all or part of this work for The long-term goal of our work is to ensure memory safety personal or classroom use is granted without fee provided that copies are for embedded software while eliminating or greatly mini- not made or distributed for profit or commercial advantage and that copies mizing the need for runtime checks and garbage collection. bear this notice and the full citation on the first page. To copy otherwise, to Because this goal is impossible with ordinary language fea- republish, to post on servers or to redistribute to lists, requires prior specific tures such as arbitrary dynamic memory allocation, aliases, permission and/or a fee. LCTES’03, June 11–13, 2003, San Diego, California, USA. and array references, our strategy is to impose (minimal) Copyright 2003 ACM 1-58113-647-1/03/0006 ...$5.00. semantic restrictions on programs necessary to achieve this 69 goal with existing compiler technology, and to reduce these The key to our approach is that we do not prevent uses of restrictions by developing new compiler techniques. dangling pointers to freed memory (e.g., a read, write, or In previous work, we addressed the limited class of real- free on an already freed storage location); instead, we en- time control applications (which typically use very simple sure statically that such operations cannot cause violations data structures and memory management) by designing a of type safety or memory safety. restricted subset of the C language appropriate for such pro- The specific contributions of this paper are as follows: grams. This language, which we called Control-C, imposed onerous restrictions on dynamic memory allocation, pointer (a) We show how to use the Automatic Pool Allocation usage, and array usage [15]. We showed that with these transformation to ensure the safety of references to restrictions, existing compiler technology can permit 100% dynamically allocated memory. We use an interpro- static checking of memory safety for this language. Unlike cedural flow analysis of the compiler-generated pool real-time control codes, however, other kinds of embedded operations to pinpoint data structures for which our applications use dynamically allocated memory and arrays approach could lead to increased memory consumption in much more complex ways, and the restrictions in Control- by the program. The analysis also identifies pools for C would preclude writing such applications. which individual object deallocation can be completely A major technical challenge for broader classes of embed- eliminated, without increasing memory consumption. ded applications is allowing flexible dynamic memory allo- cation and deallocation without runtime checks or garbage (b) We extend our previous program restrictions and com- collection. Proving statically that a general C program (for piler analysis for ensuring array access safety in order example) never dereferences a freed pointer (the “dangling to support some common features that were disallowed pointer” problem) is undecidable. before, including string manipulation, standard I/O Several recent languages including Real-time Java [4], operations, and argument vectors. Cyclone [13], Vault [7], and others [26, 9, 5] have intro- duced language mechanisms for region-based memory man- (c) We evaluate how effective the new techniques in this agement. In this approach, the heap is partitioned into sep- paper (and other compiler safety checks retained from arate regions and deallocation is only permitted on an entire the previous work) are in permitting static checking region at once. These mechanisms guarantee the safety of of memory safety, using a diverse collection of embed- pointer-based accesses to region data without garbage col- ded programs from two widely used benchmark suites, lection, but have two key disadvantages: MiBench [12] and MediaBench [19]. (1) Converting programs to use region-based mechanisms Our experimental results show that we are able to stati- demands significant manual effort, typically requiring cally ensure the safety of pointer and dynamic memory us- region annotations on pointer variables, function in- age in all these programs. Our compiler analysis identifies terfaces, and allocation sites. specific data structures in two of these programs where our memory management strategy could lead to some (probably (2) These region management schemes disallow explicit small) potential increase in memory consumption. Overall, deallocation of individual objects, so data structures the approach promises safe dynamic memory management that must shrink and grow frequently (and have ob- without the overheads of runtime checks, and with negligible jects with non nested life times) have to fall back on manual programmer effort. We believe that this is a major a separate garbage-collected heap [4, 11] to avoid po- step towards achieving our long-term goal of 100% static tentially unbounded growth in unused memory. enforcement of memory safety for embedded programs. Automatic region inference algorithms have been devel- Our results also show that two other essential techniques oped that solve the first issue completely or partially, but developed in our previous work are adequate for the pro- only for languages with no explicit deallocation such as grams studied here: a novel memory initialization strategy ML [25] and Cyclone [11] (i.e., languages

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    12 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us