Protecting dynamic code

Gang Tan, Ben Niu
{"title":"Protecting dynamic code","authors":"Gang Tan, Ben Niu","doi":"10.1145/3129743.3129746","DOIUrl":null,"url":null,"abstract":"One important aspect of making Control-Flow Integrity (CFI) practical is to support modularity. In the context of CFI, modularity refers to the ability to perform instrumentation of modules of an application separately, without considering other modules, and to link instrumented modules into an executable on demand. Modularity support is of crucial importance for accommodating dynamic linking, which loads libraries at runtime and is frequently used in modern software systems since it allows different software vendors to work on or update modules independently. Just-In-Time (JIT) compilation also requires modularity support because a piece of newly generated code by a JIT compiler can be considered a module, which is to be \"linked\" with the JIT compiler. In both dynamic linking and JIT compilation, not all code is available statically. The code of a dynamically linked library is available only after the library has been loaded at runtime, which may happen during the middle of a program execution; in JIT compilation, the binary code of a function is available only after the function has been compiled on the fly. We call this kind of code dynamic code since it is available only after a runtime event. Unfortunately, many CFI systems require all modules of an application, including libraries, to be available at the static instrumentation time. They perform a global analysis on all code to construct a global Control-Flow Graph (CFG). Instrumentation schemes in many CFI systems also assume global code properties. For instance, instrumentation in the classic CFI [Abadi et al. 2005a] inserts identifiers (representing a class of indirect branches and targets) before branch targets and inserts checks before indirect branches to make sure the right identifiers according to the CFG are at the targets. The identifiers are embedded as instructions in code and cannot appear in the rest of the code. However, this property cannot be guaranteed without inspecting the whole program. Many other CFI instrumentation techniques also do not support modularity; the reasons for this are discussed in Section 2.5. In this chapter, we present a modular CFI system that extends CFI to support dynamic code.We start with an overview of the main challenges and solutions when dealing with dynamic code in Section 2.1. In Section 2.2, we present a compilerassisted, type-based scheme that allows efficient CFG construction in the presence of dynamic code. In Section 2.3, we present a modular CFI system that supports dynamic libraries by adopting the type-based CFG construction process and a technique for supporting multi-threading. In Section 2.4, we show that, with some adjustments, the modular CFI system can support JIT compilation. We discuss related work in Section 2.5 and conclude in Section 2.6. The main results of this chapter were published in previous conference papers [Niu and Tan 2014a, Niu and Tan 2014b] and in a Ph.D. dissertation [Niu 2015]. In this chapter, we streamline the presentation by integrating the previous papers and by highlighting the most important ideas and messages that are of interest to future CFI research. Certain details are omitted and interested readers are referred to the previous papers. Furthermore, experimental results included in this chapter may be different from those in the conference publications because we have made improvements since their publication.","PeriodicalId":267501,"journal":{"name":"The Continuing Arms Race","volume":null,"pages":null},"PeriodicalIF":0.0000,"publicationDate":"2018-03-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"The Continuing Arms Race","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/3129743.3129746","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 0

Abstract

One important aspect of making Control-Flow Integrity (CFI) practical is to support modularity. In the context of CFI, modularity refers to the ability to perform instrumentation of modules of an application separately, without considering other modules, and to link instrumented modules into an executable on demand. Modularity support is of crucial importance for accommodating dynamic linking, which loads libraries at runtime and is frequently used in modern software systems since it allows different software vendors to work on or update modules independently. Just-In-Time (JIT) compilation also requires modularity support because a piece of newly generated code by a JIT compiler can be considered a module, which is to be "linked" with the JIT compiler. In both dynamic linking and JIT compilation, not all code is available statically. The code of a dynamically linked library is available only after the library has been loaded at runtime, which may happen during the middle of a program execution; in JIT compilation, the binary code of a function is available only after the function has been compiled on the fly. We call this kind of code dynamic code since it is available only after a runtime event. Unfortunately, many CFI systems require all modules of an application, including libraries, to be available at the static instrumentation time. They perform a global analysis on all code to construct a global Control-Flow Graph (CFG). Instrumentation schemes in many CFI systems also assume global code properties. For instance, instrumentation in the classic CFI [Abadi et al. 2005a] inserts identifiers (representing a class of indirect branches and targets) before branch targets and inserts checks before indirect branches to make sure the right identifiers according to the CFG are at the targets. The identifiers are embedded as instructions in code and cannot appear in the rest of the code. However, this property cannot be guaranteed without inspecting the whole program. Many other CFI instrumentation techniques also do not support modularity; the reasons for this are discussed in Section 2.5. In this chapter, we present a modular CFI system that extends CFI to support dynamic code.We start with an overview of the main challenges and solutions when dealing with dynamic code in Section 2.1. In Section 2.2, we present a compilerassisted, type-based scheme that allows efficient CFG construction in the presence of dynamic code. In Section 2.3, we present a modular CFI system that supports dynamic libraries by adopting the type-based CFG construction process and a technique for supporting multi-threading. In Section 2.4, we show that, with some adjustments, the modular CFI system can support JIT compilation. We discuss related work in Section 2.5 and conclude in Section 2.6. The main results of this chapter were published in previous conference papers [Niu and Tan 2014a, Niu and Tan 2014b] and in a Ph.D. dissertation [Niu 2015]. In this chapter, we streamline the presentation by integrating the previous papers and by highlighting the most important ideas and messages that are of interest to future CFI research. Certain details are omitted and interested readers are referred to the previous papers. Furthermore, experimental results included in this chapter may be different from those in the conference publications because we have made improvements since their publication.
保护动态代码
实现控制流完整性(CFI)的一个重要方面是支持模块化。在CFI的上下文中,模块化指的是在不考虑其他模块的情况下单独执行应用程序模块的插装,并将插装的模块按需链接到可执行文件中的能力。模块化支持对于适应动态链接至关重要,动态链接在运行时加载库,并且在现代软件系统中经常使用,因为它允许不同的软件供应商独立地处理或更新模块。即时(JIT)编译还需要模块化支持,因为JIT编译器新生成的一段代码可以被视为一个模块,该模块将与JIT编译器“链接”。在动态链接和JIT编译中,并非所有代码都是静态可用的。动态链接库的代码只有在运行时加载库之后才可用,这可能发生在程序执行的中间;在JIT编译中,函数的二进制代码只有在该函数被动态编译之后才可用。我们称这种代码为动态代码,因为它仅在运行时事件之后可用。不幸的是,许多CFI系统要求应用程序的所有模块(包括库)在静态检测时可用。他们对所有代码执行全局分析,以构建全局控制流图(CFG)。许多CFI系统中的检测方案也假定了全局代码属性。例如,经典CFI中的检测[Abadi等人,2005a]在分支目标之前插入标识符(代表一类间接分支和目标),并在间接分支之前插入检查,以确保根据CFG的正确标识符位于目标处。标识符作为指令嵌入到代码中,不能出现在代码的其余部分中。但是,如果不检查整个程序,则无法保证此属性。许多其他CFI仪器技术也不支持模块化;原因将在2.5节中讨论。在本章中,我们提出了一个模块化的CFI系统,扩展了CFI以支持动态代码。我们首先概述2.1节中处理动态代码时的主要挑战和解决方案。在第2.2节中,我们提出了一个编译器辅助的、基于类型的方案,该方案允许在动态代码存在的情况下高效地构建CFG。在2.3节中,我们提出了一个模块化的CFI系统,该系统通过采用基于类型的CFG构建过程和支持多线程的技术来支持动态库。在第2.4节中,我们将展示,通过一些调整,模块化的CFI系统可以支持JIT编译。我们将在2.5节讨论相关工作,并在2.6节结束。本章的主要成果发表在之前的会议论文[Niu and Tan 2014a, Niu and Tan 2014b]和博士论文[Niu 2015]中。在本章中,我们通过整合以前的论文并突出未来CFI研究感兴趣的最重要的思想和信息来简化演示。某些细节被省略,感兴趣的读者可以参考以前的论文。此外,本章中包含的实验结果可能与会议出版物中的结果不同,因为我们在会议出版物发表后进行了改进。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 求助全文
来源期刊
自引率
0.00%
发文量
0
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
确定
请完成安全验证×
copy
已复制链接
快去分享给好友吧!
我知道了
右上角分享
点击右上角分享
0
联系我们:info@booksci.cn Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。 Copyright © 2023 布克学术 All rights reserved.
京ICP备2023020795号-1
ghs 京公网安备 11010802042870号
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术官方微信