github
https://github.com/NWU-NISL-Fuzzing/COMFORT
Abstract
P1: 背景：为了提升效率，应当遵循ECMAScript规范，但是有难度
P2:
工具: COMFORT
任务：探测偏离ECMAScript规范的JS引擎行为及bugs
主要方法：深度学习来生成JS test code
实验A:
测试对象：10个主流JS引擎
时长200hr
效果：
- 在10个引擎种都找到了bug
- 找到了158个bugs，其中129得到了确认，115已经被fixed，21个被加入了test262，即ECMAScript官方测试集
1.Intro
P1: JS用途广;ECMA规范复杂
P2:
fuzzing常用；
fuzzing常和差分测试合起来用；
test case：在针对JS的fuzzing中，生成的testcase + 输入，二者合起来称为一份test case
潜在的bugs可能来自crash, freeeze, 差分时inconsistent compliation or execution outcomes
P3:
生成test case很难
已有方法:
- generative:
- 使用grammar
- 从program corpus中重新组合code segments
- mutational:需要已有的testcase来重新组合
已有方法的问题：需要人工构建语法，或者需要高质量种子集合
P4:
本文提出COMFORT，生成式fuzzer
集中于性能bugs，
主要方法:使用了GPT-2来生成test case
本文认为GPT-2可以更好地对程序中存在的依赖关系进行建模
P5:
现有的编译器fuzzers一般都要依赖变量的类型信息来生成随机test case中的kernel或者functional parameters，但是js是weakly typed language，同个变量名不仅能够代表任意类型的数据，还能代表多个变量。这点使得input settings的空间变得更大。
为此，就需要一种方法来提高测试效率，这里COMFORT直接用了ECMA规范本身，不过具体利用方法到这里还不明确（似乎就是直接学习了Test262)。
COMFORT draws hints from ECMA-262. It leverages the well-structured specification rules defined in the specification document to narrow down the scope of argument types and boundary values for JS APIs and edge cases that are likely to trigger unusual behavior.
P6: 介绍实际效果
实验A:
测试对象：10个主流JS引擎: Apple Safari的JavaScriptCore, Google Chrome的V8，Edge的ChakraCore, Firefox的SpiderMonkey, 嵌入式的Hermes, QuickJS, Rhino, Nashorn, JerryScript，兼容ECMAScript 2020的Graajs
时长200hr
效果：
- 80%测试用例都是语法有效的，是DeepSmith的2.6倍
- 相同的运行时间内比现在的fuzzers探测到的bugs数目多了2倍
- 在10个引擎种都找到了bug
- 找到了158个bugs，其中129得到了确认，115已经被fixed，21个被加入了test262，即ECMAScript官方测试集
2. Background and motivation
2.1 JS Standard
介绍了ECMA262以及其测试集合Test262（具有38k test cases)
2.2 Problem Scope
Definition 2.1 Conformance bug
只要是和规范不同的都称为conformance bug
Given implementations of multiple JS engines J and a version of the ECMA-262 specification E, a conformance bug is an unexpected behavior in J that occurs due to a violation to the specification in E.
Definition 2.2 Conformance testing
感觉不到定义的必要性
COMFORT只测和ECMA262相关的conformance bug，而且会人工检验，确保出现bug的feature被待测JS引擎所支持
2.3 Using JS Specification for Fuzzing
为了产生Fig2所示测试用例，fuzzer需要了解上下文，即，它需要产生一个String对象，并确保在传递给substr之前未定义len变量，本文认为传统fuzzer生成这样的测试用例是比较难的（真的么？）
2.4 Transformer-based Test Program Generation
用了开源提前训练好的GPT-2模型
3 COMFORT
- 从ECMA262中提取JS API规则
- 用GPT-2程序生成器来生成随机JS程序
- 为测试程序构建多个input-从程序中提取API，然后查询API的一些边界值来填入
- 差异测试
- 测试用例reduction
- incrementally built knowledge base来自动分析测试结果以过滤掉可能触发相同的错误行为的用例
3.1 Extracting ECMA-262 Specification
输入： HTML版本的ECMA262
步骤:
- 分析元数据，确定function, class或者object的scope
- 人工写了正则表达式抽取信息，再用Tika(a content analysis library）来抽取metadata
- 具体人力大概1周，可重复使用
- 抽取得到的metadata AST将被标注boundary conditions和literals，然后存为JSON
- 获取的rules将用来生成AST的boundary conditions
Note: 这一套方案大概覆盖了ECMA262(2019版)的82% API
3.2 Test Program Generation
Language Model
GPT-2, instruction/constant/variable都有对应vocabulary和编号，vocabulary遵循Byte Pair Encoding
如何构建vocabulary: 目的: 用尽量少的tokens数目将词划分为subwords，再将subwords对应到vocabulary table的序号上
- 统计每个词的词频，然后根据词频将每个词分成小块(chunks or subwords)
- 例如var, for, if等keywords将被划分为一个完整的词，而一些不常出现的word，比如变量名，就会被划分为更小的块，比如直接成为若干字符的集合。
Model training
训练语料: 4k个JS项目中，取到14k JS程序
训练层数: GPT-2的最后两层
Adam(0.0001, 10% decay) + 150k iteration each epoch + 100 epochs
GTX 2080Ti 30 hr
JS program generation
每次用随机数从2000个function header中选出一个header(比如 “var a = function(assert) {”) ，然后放入GPT-2中生成剩余的部分
top-10
用JSHint移除掉语法无效的输入
3.3 ECMA-262-guided Test Data Generation
变异：
使用离线提取的ECMA-262规则来确定应将多少个参数传递给一个函数，以及每个参数的类型和值。对于每种参数类型，我们根据（1）根据ECMA-262规范的边界条件（例如，在图1中，参数len设置为undefined）和（2）正常条件（使用随机值）对值进行突变。为了使变量值发生突变，我们通过遍历JS程序的控件和数据流图（第8行），将传递给函数的参数与函数的定义关联起来。
3.4 Differential Testing
使用多数表决方案，通过比较编译和执行的结果来确定哪个编译器的行为与其他行为有所不同。
忽略了所有JS引擎都不会在十分钟内终止的测试用例，因为这很可能是由于测试程序中的循环较大或无限循环所致。
3.5 Test case Reduction
遍历AST，不断删掉一些结构
3.6 Filtering Identical Miscompilation
如果已经存在一个路径，该路径给出了相同的信息（被测试用例放置）。如果是，则我们认为找到了以前识别的错误。
目前已经积累了2300个叶节点的知识库
4 Experimental Setup
4.1 JS Engines
4.2 Testbeds
- normal mode
- strict mode-ECMAScript5
区别: Strict mode可能和normal mode的语义不同，比如一些JS silent errors在ECMA Script5中就会显式抛出。本文之后报告的bugs一般都是在normal mode和strict mode都找到的bugs
4.3 Test Case Generation
COMPORT首先生成300k测试用例，然后用JSHint，在保留10k语法不正确的test cases的条件下，最后大约拿到250k test cases
4.4 Competitive Baselines
Fuzzilli, CodeAlchemist, DIE, Montage
4.5 Hardware Platforms
Our evaluation platform is a multi-core server with a 3.6GHz 8-core (16 threads) Intel Core i7 CPU, four NVIDIA GTX 2080Ti GPUs and 64GB of RAM,running Ubuntu 18.04 operating system with Linux kernel 4.15.
5 Experimental Results
P1: 运行参数，比如运行时长
P2: bugs数目分布
5.1 Quantitative Results
分别在bugs数目分配，类型分布（是通过test program generation的还是利用ECMA规范的），API分布和组件分布来描述了发现的结果
5.2 Bug Examples
基本会描述
- 例子本身的逻辑
- 哪些引擎有此问题，哪些没有，为甚么，不同的行为
- 会被如何利用
5.3 Compare to Prior Compiler Fuzzers
从bug数目（COMFORT发现的错误数目，类别覆盖数目，交并差情况和仅仅由COMFORT发现的错误数目），其他fuzzers生成的但是COMFORT无法生成的test case（包括为甚么，比如训练语料里面没有这个函数，undefined behavior）基本例子，COMFORT自身的test case质量(syntax passing rate, coverage(statement, function, branch))对比
5.4 Bug Importance
我们报告的大多数错误已被开发人员确认并修复，从而说明了它们的相关性和重要性
5.5 Discussion and Future Work
- ECMA-262中仍然以自然语言形式给出了一些定义。 Comfort不涵盖这些内容，并且可能仍需要专家参与才能了解如何手动创建测试用例生成规则或编写要覆盖的测试用例。
- 测试浮点数
- 将训练结果转化为语言规范
- 语料不足的困扰-js上很小
6 Related Work
Program Generation
jsfunfuzz, Domato, PHOG, CSmith, CLSmith
区别： deep learning
Program Mutation
SYMFUZZm Langfuzz, AFL, IFuzzer, DIE, CodeAlchemist
区别: 1. 黑盒，不需要源码
AutoTest
区别: COMFORT只测编译器相关的
Deep Learning for compiler testing
DeepSmith, DeepFuzz, Montage
本文: 神经网络更先进复杂
Conformance testing for JS
JEST, JISET
JISET基于变异