阅读笔记：[LEGO]Sequence-Oriented DBMS Fuzzing

语句亲和性如何评估？代码覆盖率
SQL类型序列：红圈部分

SQL类型序列的多样性是由其组合、排列顺序共同决定的——组合相同、顺序不同的SQL序列覆盖的功能可能是不一致的：

现有的工作注重SQL语句的合法性，忽略了SQL类型序列的多样性

实现多样性不能简单的枚举SQL序列，有以下三点原因：C1、组合爆炸；C2、很多序列实际上是无意义的；C3、不是所有序列都适合fuzz（fuzz是计算密集型任务，复杂的SQL序列可能会导致fuzz过程漫长）。

现有的fuzzer面对以上三点挑战：
基于生成的fuzzer（SQLsmith和SQLancer）：C1、C2——手动添加生成规则，耗费人力且多样性有限；C3——简化规则可以提升执行速度，但会降低覆盖率
基于突变的fuzzer（SQUIRREL 和 RATEL）：C1、C2——缺乏从极大的状态空间中突变出有意义和强多样性序列的方法；C3——多次执行运行快的种子、以覆盖率为指标修减种子，但仍然会有运行时卡住的大种子（复现QPG时的亲身经历，150G的大种子，卡半天Orz）。

LEGO针对以上三点挑战：
C1、C2——主动发掘语句亲和性
C3——限制最大语句长度，同时应用序列综合，容纳不同长度的序列

学习到语句亲和性后，LEGO合成的新语句通常长度较短、SQL结构较简单，但SQL种类较丰富。

三种变异方式：替换 插入 删除
SQL statement的类型判别：AST model

一个SQL Type Sequence会被实例化多次（不同的AST）
根据骨架（SQL Type Sequence）和AST生成的testcase可能存在语法和语义错误，LEGO会构建SQL语句的数据依赖图，用正确的数据进行修复。

复现思路：
①语句亲和性的寻找（算法1、2）——清晰，但通过AST model判别SQL statement type的方法尚不明确，文章没有具体展开；算法1中判断覆盖率增加的函数hitNewBranch如何实现也没有展开
Ⅲ-A-3）We use an AST model to accurately identify statement types. The model is built from DBMS’s grammar specification to support identifying all statement types and other structures.

②运用亲和性生成SQL sequence（算法3）——清晰。

③SQL sequence生成之后，如何实例化（填充具体内容）——Ⅲ-B-最后两段简要提到（先生成AST，转换为SQL语句，再通过构建的数据依赖图修复），但是没有具体展开。