Proj THUDBFuzz Paper Reading: Sulong, and Thanks For All the Bugs: Finding Errors in C Programs by Abstracting from the Native Execution Model
Abstract
- 介绍memory error的重要性
- 当前研究：low-level execution model, 额外的检查，问题：可能忽略corner cases
本文工具: Safe Sulong
方法： 将high-level中的数据结构与C中映射，然后用解释器来做自动检查
效果：能找到被忽视的bugs
1. Intro
本文:
主要技术: dynamic bug-finding，找ASan和Valgrind找不到的bugs
找不到的原因:
- 现有的方法无法从机器本身的执行模型中抽取宏观信息
- 缺乏源码信息
- a check can easily be forgotten(Q)，而且常常使用不完全准确的结束
- 在native code水平上有一定操作的bug-finding tools常常提供restricted bug-finding coverage，这会使得用户误以为自己已经安全了，比如out-of-bounds accesses to main argument
本文: Safe Sulong
目的: detect out-of-bounds accesses, use-after-free errors, invalid free errors, double free errors, NULL dereferences, and accesses to non-existent variadic arguments.
主要方法:
- 对机器的执行模型进行抽象化，使用用高级语言写的C执行环境，将指针等C数据结构封装起来，在上面做很多自定义检查
- 为了加速，使用了动态编译器。该方法不会将bugs优化掉，是按照Felleisen优化代码
效果 - 有应用在其他语言上的潜力
- exact且能够找到某种类型的全部错误
- 不提供未被编译过的native code的操作，因为这可能损害bug-finding能力
- 在小型开源项目上找bugs，找到68个bugs
- 难以在诸如浏览器等大型项目种使用,warm-up代价过高
2. Background
2.1 Errors in C
Out-of-boundsaccessesUse-after-freeerrors- NULL dereferences
- Other errors: 1. invalid free errors：尝试释放stack onject, global object或者从object的中间开始释放 2. double free errors 3. 访问不存在的可变参数，常常是由于传去的可变参数个数小于预期
2.2 State of the Art
Shadow Memory
ASan, Mudflap, Valgrind, Dr.Memory， SoftBound+CETS, Purify
都维持一个shadow memory, 里面会放上一些关于内存的metadata
常与redzone一起使用
Compile-time instrumentation
ASan: initially detected out-of-bounds accesses, use-after-free errors, and NULL dereferences [55] and has been extended to detect invalid free, double free, and use-after-scope (including useafter-return as a special case) errors as well as memory leaks
SoftBound+CETS: a bounds checker with a temporal memory safety tool
Mudflap: s used by the GCC project until GCC 4.9，有以下问题：reporting false positives and not detecting buffer overflows for neighboring objects in the memory
Purify: 商业化工具， inserts code into object files
Dynamic instrumentation
特点：不需要重新编译，适用于任何可以编译为机器码的语言
主要方法：在二进制直接进行检查
Valgrind
Dr.Memory
Intel Inspector
Other approaches
Polymorphic C, Cyclone, CCured: 需要对源代码进行修改
Canary-based approaches: 只能检测invalid writes
2.3 Limitations of Current Approaches
P1: Lack of abstraction from the machine
Q
P2: Compiler optimizations
实际上bug-finding tool和编译器所接触到的语义有所不同，比如
可能导致假阴：
可能导致假阳：
ASan: load-widening（将一系列load指令打包在一起成为单个load指令)，由于平台相关的对齐政策，可能拿到超过边界的数据，但是并不是越界错误实际上无需报告
即使使用-O0也不能完全阻止编译器把bugs优化掉
P3: Inexact approaches
P4: Finding invalid accesses in libc
3. Implementation
- 使用了Java写的解释器来执行C代码
- 写了自己版本的为了发现bug的libc
- 使用不会优化掉invalid accesses的方法做代码优化
3.1 System Overview
Libc
本文的：
特点: 不依赖于任何GNU extensions，基于运行时信息的额外检查
没写完的： threads, synchroniztion, interprocess communication, 一些low-level operation和比较少用到的函数
Clang and LLVM IR
使用Clang来做优化
Truffle
使用Truffle来做LLVM IR interpreter，需要写一个AST解释器，每个操作是一个可执行节点
Graal
将频繁执行的Truffle ASTs编译为机器码
这里如果假设不成立，就不再优化，只用解释器执行AST
由于是基于safe
LLVM IR Interpreter
Safe Sulong地核心，
JVM
需要JVMCI
