PLDI‘02 ESP: Path-Sensitive Program Verification in Polynomial Time - 路径敏感分析ESP: Property Simulation

​ 这篇文章发表在PLDI’02, 作者的相关工作分析了1.4 millions LOC (微软word 97)。ESP同时也借鉴了Metal Checking System (Coverity) 一些想法

我的关注点在于, 一般地，我们认为：目前还没有比较好的方法在IFDS框架上做路径敏感的数据流分析，而这篇文章提出的算法能够被实现在IFDS框架上。(不过文中提到对执行状态的处理是上下文不敏感的)

1. 简介

​ 这篇文章，作者提出partial program verification一个新的算法：property simulation。算法关注于程序的temporal safety property。它是路径敏感的，与完全路径敏感的指数级开销相比，作者的算法时间/空间开销是多项式的。

​ 作者开发了一个检查工具叫做ESP(Error delection via Scalable Program analysis)，而property simulation作为此工具的一部分。

​ 作者用这个工具验证了gcc (140,000 LOC, 2.5.3 from SPEC’95) 的IO行为是否正确，证明了646个对sprintf的调用都是合理的。试验结果证明它能够scale到大规模程序，并且对一些程序的属性能够足够精确地验证。

​

​ 对于Temporal safety property。可以简单地理解为一些能够用有限状态自动机(Finite State Machine, FSM)描述的程序属性。如果错误状态从不可达，那么就证明程序遵循安全属性。

​ 对于路径敏感。路径敏感对于控制误报数是必要的。但是用简单的方法追踪程序分支的状态，开销比较大。作者观察到：给定一个需要验证的程序属性，分支虽然会影响程序的执行状态，但是大部分分支可能都跟需要验证的属性无关。所以作者的property simulation算法是启发式的，它基于这样的一个认识：如果沿着分支执行会导致FSM状态变化，那么这个分支就是需要关心的。所以这种敏感是对property state路径敏感的。

​ 所谓property state, 就是符号化地去执行程序(symbolicly evaluate program), 生成符号状态; 符号状态由两部分组成：

​ (1). 执行状态

​ (2). FSM的属性状态。

​ 具体而言，在控制流交汇处，考虑如下两种情况，能够避免指数级爆炸，同时又能考虑到分支行为。

​ (1). 如果符号状态有相同的执行状态，那么就像数据流分析一样，将FSM的状态进行合并。

​ (2). 否则，类似路径敏感分析，单独处理符号状态。

​ 文章的贡献：

​ (1). 提出一个property simulation框架，能够切换3种不同的执行方式：完全路径敏感，普通数据流分析，property simulation。

​ (2).作者给出一个框架的例子，它的程序属性是类constant propagation lattice。他是多项式级别的时间/空间开销。

​ (3). 给出ESP的系统大概。它组合了scalable的alias analysis和property simulation，能够检查multiple stateful values（文章给的例子是追踪单值）

​ (4). 试验结果。accurate，scalable

2. 例子描述

​ 给定一个对文件句柄操作行为的FSM。

​ 给定一个代码片段，用于说明问题：

​ 作者描述了三种方式去检测这段代码：

​ (1). full path-sensitive

​ (2). stand dataflow analysis

​ (3). Property simulation

​ (1). 完全路径敏感： 在l: if (dump)...这条语句之前，有两个分支语句，那么有4条路径，枚举得到4种可能情况。(下图中二元组第一个元素表示属性状态，第二个元素表示程序的执行状态)

​ (2). 标准数据流分析： 在控制流交汇处，合并状态得到[{$uninit, Opened}], 即既可能未初始化，又可能处于关闭状态，于是到fclose时，误报。

​ (3). Property Simulation: 第二个条件不会影响FSM的状态。所以相比完全路径敏感的4个状态，property最后只有两种状态。[$uninit$, $\neg$ dump], [Opened, dump]

3. Intra-Procedural Analysis

3.1 算法简介

​ (0). CFG预设：$n_{entry}$表示cfg的入口；merge点只有2个前驱；branch点只有一个前驱，一个true后继，一个false后继；计算节点(普通节点)只有单个前驱，单个后继。

​ 先给出intra-procedural的算法，再细说：

​ Intra-procedural分析较为简单。可以按照传统的数据流分析来看待，先定义Domain，再定义Transfer Function。

​ (1). 定义抽象域：

• $D$: FSM (property state machine)状态的集合

• $S$: Symbolic State的集合

  • Symbolic State: <abstract state, execution state>
    • 抽象状态是property state的集合
    • 执行状态中 $\top$ 表示所有行为，$\perp$表示无行为
  • $s\in S,as(s)表示符号状态的抽象状态,es(s)表示符号状态的执行状态$

• dataflow fact就是2${}^S$

​ (2). 定义Flow Function:

• $F_{mrg}$ ：控制流交汇处合并多个分支的dataflow fact，形成单个dataflow fact

• $F_{br}$：分支处从入边得到输入的符号状态集，使用$f_{br}$ 作用于输入状态得到输出状态；其中$f_{br}$ 有两种作用

  • 根据输入的执行状态，使用定理证明器，查看当前分支是否可行
    • 如果true/false与否可知，那么就可以忽略探索不必要的分支
  • 如果从输入的执行状态中推倒不出当前分支的true/false与否，那么就往分支的true/false边(branch predicate)继续执行。

• $F_{oth}$ 对于一般的计算节点，$f_{oth}$ 可能会更新抽象状态(根据FSM的转换关系)，也可能会更新执行状态
  

​ (3).Group Function：上图中有个$\alpha$ 函数，叫做Group Function，用于合并执行状态。通过它可以配置整个框架在3中分析模式中进行切换，如上文所示的3中分析模式：完全路径敏感的分析，标准数据流分析，property simulation分析

• ${\alpha }_{cs}$：完全路径敏感
  • 不对执行状态进行合并，为identity function
• ${\alpha }_{df}$：标准数据流分析
  • 合并所有的符号状态，成为单个符号状态
    • 这种合并导致特定执行状态下的property state信息会丢失
  • 一种高效的方式就是固定执行状态为$\top$ ,表示所有可能的行为
• ${\alpha }_{as}$：Property Simulation
  • 根据property state分组。例如： α a s ( [ { a } , l ] , [ { a } , m ] , [ { b } , n ] , [ { b } , o ] ) = [ { a } , l ⊔ m ] , [ { b } , n ⊔ o ] α_{as} ({[\{a\}, l], [\{a\}, m], [\{b\}, n], [\{b\}, o] }) = {[\{a\}, l \sqcup m], [\{b\}, n \sqcup o]} αas​([{a},l],[{a},m],[{b},n],[{b},o])=[{a},l⊔m],[{b},n⊔o]
  • 该函数用于维护一个给定的property state和执行状态之间的关联：在这种执行状态下，FSM会被驱动到另一个状态。

总而言之，Property Simulation可以被当成是一种组合执行状态的技术，同组的执行状态，蕴含着特定的property state 。这种组合能够让我们控制分析的复杂度。

3.2 对比例子

​ 上图中，左侧为False分支的状态，右侧包括True分支的状态，以及Merge之后的状态。

• PSA 为 Path-Sensitive Analysis，PropSim为Property Similation，Dataflow为数据流分析

• 图上的一些缩写

  • dump缩写d
  • [p->F, d-> T] 缩写 !pd
  • $uninit缩写为$u
  • Opened缩写o

​

4. Inter-Procedural Analysis

​ 函数间分析，理解了intra-procedural analysis后，inter-procedural analysis也很简单，主要是Call和Exit节点的处理，需要注意Summary的记录与重用。[1] [2]

​ 还需要注意的是AddTrigger函数。如果执行状态的Domain是无限的，那么上下文敏感的property simulation可能不会终止，因此，我们需要对property states上下文敏感；而对于执行状态，实现非上下文敏感，即合并不同调用点处函数入口的执行状态。

​ 该算法可以在IFDS/IDE框架之上实现。

​ Property Simulation足够精确的原因是因为，它设计之初就将程序员对特定执行状态下的特定程序属性的编程考虑，进行显式化。

5. ESP工具

​ 关于ESP工具，作者没有给出详细的算法，但是给出的执行步骤，还是比较经典的。现在的很多论文中都能看到一些影子。

​ 上文都是描述对单个值的追踪，ESP (Error detection via Scalable Program analysis)工具则组合别名分析和property simulation来追踪多个值的状态。

​ ESP借鉴了Metal checking system[3] [4]的想法 (没错, 就是Coverity)。Metal可以让程序员通过写代码的方式来提供FSM规约。

​ ESP的多值状态的追踪，分为两步骤：(1). 执行highly scalable流不敏感，上下文敏感的value-flow来找到每个函数调用可能影响到的状态值。(2). 对所有stateful values运行property simulation。

​ ESP限制编写的规约只能关联单个状态，这样就能一次分析一个状态值。

​ ESP执行如下步骤

• CFG构造

  • 跑一个scalable指向分析[5]，用于生成保守调用图

• Value-Flow计算

  • 跑一个scalable flow-insensitive, context-sensitive的指向分析[6]用于生成保守value-flow
  • 分析映射每个表达式到一个VFG (value flow graph)上的节点
    • VFG上可以查询：是否表达式e的值流向e'？
    • VFG上可以查询：是否可以通过0条或者多条值流边，存在一条从e到e'的路径

• 抽象CFG构造

  • 使用property specifification来替换特定的pattern functions成为特殊的被参数化的pattern nodes.

• 接口表达式的计算 (bottom-up切片)

  • 目的：为了精确刻画函数间的Value-Flow
  • 一个函数的inNodes：所有的全局变量，形参，以及这两者的解引用。
  • 一个函数的outNodes: 所有的全局变量，返回值，以及这两者，形参的解引用。
  • 降低集合的大小
    • inNodes, outNodes包含所有的全局变量，分析大型项目集合会变得比较大
    • 沿着调用图bottom-up的方式，可以去掉集合中的一些元素
      • 表达式e能够从inNodes中删除：如果在函数开始处到pattern处，不存在e -> e’
      • 表达式e能够从outNodes中删除：如果在函数内不存在表达式e‘上的value creation pattern，使得creation pattern到exit之间不存在边e’ -> e
  • PLDI’18 Pinpoint [7] 中描述的Connector Model感觉和这里的接口表达式类似

• Mod set计算

  • 使用bottom-up方式计算每个函数的mod sets

• Alias set计算

  • ESP通过创建借口表达式的alias sets，能够处理multiple stateful values
  • 别名用于解决：针对单个值状态的变化，会影响到与这个值互为别名的值的状态
  • inNodes的alias sets在property simulation时创建
  • outNodes的alias sets使用bottom-up切片来创建
  • 我们能把它认为是escape analysis

• Property Simulation

  • intra-procedural
  • inter-procedural

这里不放实验数据了，可以自己去看看原文^__^

6. 参考资料

[1] T. Reps, S. Horwitz, and M. Sagiv. Precise interprocedural data ow analysis via graph reachability. In Conference Record of the Twenty-Second ACM Symposium on Principles of Programming Languages, 1995.

[2] R. Wilson and M. Lam. Effiffifficient context-sensitive pointer analysis for C programs. In Proceedings of the ACM SIGPLAN 95 Conference on Programming Language Design and Implementation, 1995.

[3] D. Engler, B. Chelf, A. Chou, and S. Hallem. Checking system rules using system-specifific, programmer-written compiler extensions. In Proceedings of the sixth USENIX Conference on Operating systems design and implementation, 2000.

[4] S. Hallem, B. Chelf, Y. Xie, and D. Engler. A system and language for building system-specifific, static analyses. In Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design and Implementation, 2002.

[5] M. Das. Unifification-based pointer analysis with directional assignments. In Proceedings of the ACM SIGPLAN 2000 Conference on Programming Language Design and Implementation, 2000.

[6] M. Das, B. Liblit, M. F¨ahndrich, and J. Rehof. Estimating the Impact of Scalable Pointer Analysis on Optimization. In 8th International Symposium on Static Analysis, 2001.

[7] Qingkai Shi, Xiao Xiao, Rongxin Wu, Jinguo Zhou, Gang Fan, and Charles Zhang. 2018. Pinpoint: Fast and Precise Sparse Value Flow Analysis for Million Lines of Code. In Proceedings of the 39th ACM SIGPLAN Conference on Programming Language Design and Implementation (Philadelphia, PA, USA) (PLDI2018). Association for Computing Machinery, New York, NY, USA, 693–706. https://doi.org/10.1145/3192366.3192418