Proj THUDBFuzz Paper Reading: Sulong, and Thanks For All the Bugs: Finding Errors in C Programs by Abstracting from the Native Execution Model

Abstract

1. 介绍memory error的重要性
2. 当前研究：low-level execution model, 额外的检查，问题：可能忽略corner cases

本文工具: Safe Sulong
方法： 将high-level中的数据结构与C中映射，然后用解释器来做自动检查
效果：能找到被忽视的bugs

1. Intro

本文:
主要技术: dynamic bug-finding，找ASan和Valgrind找不到的bugs
找不到的原因:

1. 现有的方法无法从机器本身的执行模型中抽取宏观信息
2. 缺乏源码信息
3. a check can easily be forgotten(Q)，而且常常使用不完全准确的结束
4. 在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.
主要方法:

1. 对机器的执行模型进行抽象化，使用用高级语言写的C执行环境，将指针等C数据结构封装起来，在上面做很多自定义检查
2. 为了加速，使用了动态编译器。该方法不会将bugs优化掉，是按照Felleisen优化代码
   效果
3. 有应用在其他语言上的潜力
4. exact且能够找到某种类型的全部错误
5. 不提供未被编译过的native code的操作，因为这可能损害bug-finding能力
6. 在小型开源项目上找bugs，找到68个bugs
7. 难以在诸如浏览器等大型项目种使用,warm-up代价过高

2. Background

2.1 Errors in C

1. Out-of-bounds accesses
2. Use-after-free errors
3. NULL dereferences
4. 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

1. 使用了Java写的解释器来执行C代码
2. 写了自己版本的为了发现bug的libc
3. 使用不会优化掉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

3.2 Managed Objects and Type Safety

3.3 Memory allocation

3.4 Finding bugs

4. Evaluation

4.1 Effectiveness

4.2 Start up and Warm up costs

4.3 Peak Performance

5 Limitations