FRAMER: a Software-Based Capability Model

FRAMER: a Software-Based Capability Model

FRAMER: A Software-based Capability Model 1st Myoung Jin Nam 2nd Periklis Akritidis 3rd David J Greaves Korea University Niometrics University of Cambridge Seoul, S.Korea Singapore, Singapore Cambridge, UK [email protected] [email protected] [email protected] Abstract information for blocking unintended accesses to objects. These Fine-grained memory protection for C and C++ programs systems can offer deterministic guarantees, since now memory must track individual objects (or pointers), and store bounds corruption is prevented in the first place, however tracking all information per object (or pointer). Its cost is dominated objects (or pointers) incurs heavy performance overheads. by metadata updates and lookups, making efficient metadata Some existing techniques trade off compatibility for high management the key for minimizing performance impact. Ex- locality of reference, however, it is desirable to minimise the isting approaches reduce metadata management overheads by disruption owing to tacit assumptions by programmers and sacrificing precision, breaking binary compatibility by chang- compatibility with existing code or libraries that cannot be ing object memory layout, or wasting space with excessive recompiled. In particular, so-called fat pointers [35] impose alignment or large shadow memory spaces. incompatibility issues with external modules, especially pre- We propose FRAMER, a software capability model with ob- compiled libraries in software-based solutions. ject granularity. Its efficient per-object metadata management With these limitations in mind, object-capability models mechanism enables direct access to metadata by calculating [9], [28], [50], [51] using hardware-supported tags become their location from a tagged pointer to the object and a very attractive, because they can manage compatibility and compact supplementary table, and has potential applications control runtime costs. But they are not supported in today’s in memory safety, type safety, thread safety and garbage mainstream processor architectures, and, more importantly, collection. FRAMER improves over previous solutions by cannot entirely avoid undesirable overheads such as metadata simultaneously (1) streamlining expensive metadata lookups, management related memory accesses just by virtue of being (2) offering flexibility in metadata placement and size, (3) hardware-based. saving space by removing superfluous alignment and padding, In this paper, we present FRAMER, a software-based ca- and (4) avoiding internal object memory layout changes. We pability model using tagged pointers for fast metadata access. evaluate FRAMER with a use case on memory protection. FRAMER provides efficient and flexible per-object metadata management that enables direct access to metadata by calcu- I. INTRODUCTION lating their location using the (currently) unused top 16 bits Despite advances in software defenses, exploitation of of a 64-bit pointer to the object and a supplementary table. systems code written in unsafe languages such as C and The key considerations behind FRAMER are as follows. C++ is still possible. Security exploits use memory safety Firstly, FRAMER enables the memory manager freedom vulnerabilities to corrupt or leak sensitive data, and hijack a to place metadata in the associated header near the object vulnerable program’s logic. In response, several defenses have to maximise spatial locality, which has positive effects at all arXiv:1810.11622v2 [cs.CR] 1 Mar 2019 been proposed for making software exploitation hard. levels of the memory hierarchy. Headers can vary in size, Current defenses fall in two basic categories: those that unlike approaches that store the header at a system-wide let memory corruption happen, but harden the program to fixed offset from the object, which may be useful in some prevent exploitation, and those that try to detect and block applications. Headers can also be shared over object instances memory corruption in the first place. For instance, Control- (although we do not develop that aspect in this paper). Our flow Integrity (CFI) [1], [14], [20], [36], [39], [47], [48], [49], evaluation shows excellent D-cache performance where the [55], [56], [57] contains all control flows in a statically com- performance impact of software checking is, to a fair extent, puted Control-flow Graph (CFG), while Address Space Layout mitigated by improved instructions per cycle (IPC). Randomization (ASLR) hides the available CFG when the Secondly, the address of the header holding metadata is process executes. Both approaches can offer only probabilistic derived from tagged pointers regardless of objects’ alignment. security [15], [44], since memory corruption is still possible, We use a novel technique to encode the relative location of the albeit exploitation is much harder. header in unused bits at the top of a pointer. This streamlines A general approach to detect and block memory corruption metadata lookup, which has been the performance bottleneck is through tracking the bounds of object allocations [3], of deterministic memory safety approaches. Moreover, the [5], [13], [16], [19], [21], [23], [26], [33], [34], [35], [41], encoding is such, that despite being relative to the address in [54]. The program is instrumented accordingly to use bounds the pointer, the tag does not require updating when the address in the pointer changes. A supplementary table is used only for cases where the location information cannot be directly ad- OBJECT OBJECT LB dressed with the additional 16-bits in the pointer. The address P UB LB UB P of the corresponding entry in the table is also calculated from our tagged pointer. This table is small compared to typical 64 64 64 32 32 shadow memory implementations. (a) Fat pointers (b) SGXBounds Thirdly, we avoid wasting memory from excessive padding Fig. 1: Embedded Metadata: P, UB, and LB represent a pointer itself, and superfluous alignment, by encoding and using relative upper bound, and lower bound, respectively. location for metadata access. Whereas existing approaches that are never dereferenced. Object-based approaches usually using shadow space [3], [17], [28], [33], [41] re-align or group omit tracking of sub-objects such as an array member of a objects to avoid conflicts in entries, FRAMER provides great structure. flexibility in alignment, that completely removes constraining the objects or memory. The average of space overheads of our Due to the arbitrary size of objects, these approaches require approach is 20% for full checking despite the generous size some form of range-based lookup of objects using an in-bound of metadata in our current implementation. address, which can be more expensive than a simple lookup. Fourthly, our approach facilitates compatibility. Our tag is An early approach used a splay tree to reduce the overhead encoded in otherwise unused bits at the top of a pointer, but [23], but more efficient systems simplify the lookup by using the pointer size is unchanged and contiguity can be ensured. table access to shadow memory regions. We will discuss the The contributions of this paper are the following: details in Section II-B. 2) Pointer-based tracking: Pointer-based approaches asso- • We present an encoding technique for relative offsets that ciate bounds information with pointers. Per-pointer metadata is interesting in its own right. It is both compact and holds the valid range that a pointer is allowed to point to. also avoids imposing object alignment or size constraints. Unlike object-based approaches, this enables them to detect Moreover, it is favourable for hardware implementation internal overflows easier, such as an array out-of-bounds inside and may find uses across different application domains. a structure, so pointer-based approaches can guarantee near • We design, implement and evaluate FRAMER, a generic complete memory safety. One drawback is the additional framework for fast and practical object-metadata manage- runtime overhead from metadata copy and update at pointer ment with potential applications in memory safety, type assignment, while object-based approaches update metadata safety and garbage collection. only at memory allocation/release. In addition, the number • We present a case study of applying FRAMER to the of pointers can be larger than that of allocated objects, so problem of spatial memory safety, using our framework pointer-intensive programs may suffer from heavier runtime to allow inexpensive validation of pointer dereferences. overheads. We further discuss some kinds of violations of temporal safety that FRAMER prevents, and a potential application B. Metadata Storage for type confusion prevention. Memory safety enforcement techniques fall into two cate- II. BACKGROUND AND RELATED WORK gories depending on whether metadata is disjoint or embedded In this section we discuss techniques to detect memory in each object or pointer. errors. Static analysis detects errors at compile time and does 1) Embedded Metadata: not introduce run-time overhead, but must inevitably be over- a) Fat Pointers: Fat pointers [5], [22], [35] embed conservative, giving false alarms. In this paper, we focus only metadata in each pointer as shown in Fig. 1a. They provide on run-time verification, but with compile-time assistance. speed with the highest locality of references by avoiding extra memory access for metadata update/retrieval, however, they A. Metadata Association break binary compatibility due to expansion of the pointer Several approaches have been proposed

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    15 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