Chapter 3 Locking Down Insecure Indirection with Hardware-Based Control-
3.1.3 Advancing CDI with Architecture Support
To facilitate the adoption of Control-Data Isolated code, this chapter introduces a novel, conditional branch sled-backed, capability to safely allow indirection. Our work couples an indirect jump (such as jreg, indirect call, and return) with a sled of direct compares and jumps. When indirect instructions are first encountered in a program execution they are not yet validated. Thus, they will not be executed and the sled comprising all allowable control-flow transitions for the indirect instruction is instead executed. If the sled indicates that an indirect jump target is valid, it will result in a taken conditional branch. This valid control flow edge is comprised of the indirect PC address and the target address of the taken conditional branch. This valid CFG edge is then stored in an edge cache. As indirect control- flow instructions are encountered in program execution, we first probe the edge cache by the indirect PC address and register-derived target address. If this edge is represented in the edge cache it was formerly generated by executing the direct control flow encoded in the sled. In this case, the sled is skipped, and the indirect control instruction is allowed to execute. If the indirect instruction and its proposed target cannot be validated by the edge cache, the sled is executed to its valid edge and this new edge consisting of source and target addresses is cached.
Using this approach, we ensure that all control-flow edges are validated against the whitelist of targets represented in the sleds. As our results show in Section 3.5, a trivial fraction of sleds is actually executed resulting in nearly no slowdown for this powerful control-flow protection mechanism. Additionally, we observe that the information contained in the edge cache, combined with history information, could provide double-duty as an indirect branch predictor. We propose additions to the indexing mechanism of the edge cache for prediction of indirect branches. Accurate indirect branch prediction remains an important problem in computing and continues to be the subject of contemporary research efforts [51, 118, 124]. Works such as ITTAGE [124] continue as even small improvements
to prediction rates can yield worthwhile performance gains. As such, we show that, com- pared to architectures with only simple BTB-based indirection prediction, using the edge cache additionally as an indirect predictor results in a modest speedup for CDI-compliant programs, with some applications reaching up to over 6% performance improvement.
3.1.4
Contributions of this Chapter
The primary achievements of this chapter are two-fold. The first is the elimination of the potential overheads of Control-Data Isolation remaining from the previous work of Chapter 2. The second purpose of this chapter is to extend the principles of CDI to paths of execution. The majority of this chapter is derived from the publication “Locking Down Insecure Indirection with Hardware-Based Control-Data Isolation” [10] This chapter makes the following contributions:
• We show how simple hardware and software for CDI support can guard a program from control-flow attacks.
• We demonstrate that edge caching eliminates nearly all of the slowdowns associated with the execution of indirect jump validation sleds.
• We explore how the use of the edge cache as an indirect branch predictor enables speedups for select CDI-compliant programs compared to architectures with simple BTB-based indirection prediction.
• We detail a novel hardware mechanism to extend the principal of control-data isolation toward the elimination of path-based control-flow attacks. As shown in Chapter 2, CDI eliminates contemporary control-flow attacks. In this chapter, we show how simple hardware support can eliminate future attacks in control-flow security which violate the programmer-intended paths of execution for applications.
This chapter, Chapter 3, encapsulates the following work. Section 3.2 reviews how control flow is protected by Control-Data Isolation and details how to accelerate execution of CDI-compliant code while Section 3.3 details our proposed edge cache and indirect prediction mechanisms. Section 3.4 then provides details of our implementation and Section 3.5 shows and discusses results. Section 3.7 highlights related works in control-flow security and we conclude in Section 3.8.
3.2
Protecting Control Flow with Control-Data Isolation
Arbitrary code injection attacks are the end goal for many attackers. At the heart of code injection are contemporary control-flow attacks. CDI protects against the subversion of control flow at runtime by eliminating the use of indirection.
3.2.1
Threat and Trust Model
In this work, we adopt a relaxed threat model and minimal trust model, similar to previous CDI work [12]. In our threat model, an attacker is presumed to possess great influence over a system. In this, we assume that any attacker has arbitrary and complete control over data memory. That is, an attacker is assumed to be allowed read, write, and even execute privilege over data memory.
Delineating our trust model is simple. We only presume that an attacker does not possess the ability to overwrite information from the code segment of an application at runtime. That is, we rely on memory protection of write or execute for the code of a target appli- cation. We consider this a basic tenet of security. Violation of this trust obviates the need for a control-flow attack, as arbitrary code injection would be replaced by arbitrary code replacement.