Golang (简称 Go)[1]是由 Google提议并于2009年开源的新兴编程言语. Go言语因其语法毛糙、静态强类型、自动内存管理、原生相沿高并发、编译型等特点， 得到许多开采者的认同. 2009年和2016年两度成为Tiobe编程言语名次榜的年度明星[2]. 凭证 2022年Go开采者雇佣申报[3]， 巨匠10.5%的开采东谈主员将Go作为主力编程言语， 亚洲占比最高鑫系列第二季， 达57万东谈主， 而中国更是有进步16%的开采者使用Go言语.

跟着软件无处不在， 软件的安全及服从变得越来越紧迫， 而其中内存管理方式过头达成机制对软件开采产能、安全和服从的影响尤为紧迫. 传统的 C/C++ 言语需要开采者显式决定变量是分派在栈、静态数据区、照旧堆中， 显式管理对象的分派与回收， 这使得关节极易出错， 给开采和负责带来极大的背负. 为提高内存安全性和软件开采产能， 越来越多的当代编程言语， 如Java、Python、Go 等， 提供垃圾回收(garbage collection， GC) 等自动内存管理机制， 使得开采者无需管理对象的回收. Python 接纳以援用计数为主、以分代处分轮回援用为辅的 GC[4]， 其接纳全局诠释器锁 (GIL) 使多线程在竞争时串行履行. Java 假造机如OpenJDK 则提供多种丰富的 GC 算法来专注于糊涂量 (throughput)、延伸 (latency)、或内存占用 (memory footprint) 等不同性能方针， 它们组合诈欺多线程 stop-the-world (STW， 多线程回收时让用户代码罢手履行)、分代、紧致 (compaction， 回收时间通过出动对象来紧致内存以处分碎屑问题)或不同的并发 (concurrent， 回收与用户代码并发履行) 等时刻[5]. 而 Go 的GC建立在基本莫得碎屑问题的分派器TCMalloc[6]之上， 使用的是无分代的、无紧致、并发的三色标记毁灭算法， GC算法轻量. 这些特点使得Go在特定场景下领有Python般运动的开采体验的同期， 又能达到接近C++的运行效率[7].

Go 使用逃遁分析(escape analysis)在编译阶段来决定对象是否堆分派， 使得开采者无需手动指定对象的分派位置. 现存逃遁分析联系的连接主要网络在 Java 言语上[8−13]， 而非 Go. 关于栈分派， 只需通过修改栈帧指针即可险些零支出地完因素配和回收; 而堆分派则需要 GC 承担极度平稳的分派和回收代价. Java 言语呈现给开采者的不雅点是对象在堆均分派， 而具有局部作用域的基本类型的值和对象类型的援用才会在栈上分派. 为镌汰GC 的背负， 当代Java 假造机在即时编译器中利用逃遁分析遣散来开展内存使用优化， 如将未逃遁出方法的对象进行标量替换 (即张开为一系列基本类型的值)， 进而不错自动在栈上分派[10]. Go言语则守望让路发者专注于关节功能逻辑本人， 不必指定变量或对象是分派在栈照旧堆中， 而由编译器的逃遁分析来判定对象是否逃遁到堆上， 进而决定分派的位置. Go言语的逃遁分析是编译活水线中的必要进程， 其还承担了负责Go内存安全以及GC平常运行的劳动. Go言语编译器的逃遁分析需要正确判断一个对象是否逃遁并分派在堆上， 不然极有可能产生若干内存破绽， 如悬垂指针等， 导致Go关节运行时极度步履以致崩溃 (panic)， 在执行应用环境中酿成较大亏欠.

一个正确的Go逃遁分析需要找到通盘需要堆分派的解， 使得关节不错平常运行， 不会因为内存破绽而崩溃. 可是， 面前 Go 社区中的逃遁问题频发， 据空虚足统计， 从2017年于今已有17个和逃遁分析联系的 issues (如图1所示)， 而且无减少治理趋势(如图2所示). 比如 2022年的 issue#54247 [14]， 逃遁分析和后续编译优化的合营出错， 导致本该逃遁的对象栈分派， 酿成堆对象援用了吊挂的栈指针; 2021年的issue#44614 [15]， 由于逃遁分析的分析出错， 导致全局对象援用了吊挂的栈指针. Go的GC在运行时发现不正确的指针后会成功崩溃[16]， 因此和逃遁联系的问题一朝出现， 不时都是致命的问题. 另外， 由于GC不是这种无剃头生的第一现场， 因此不时难以定位这种运行时崩溃产生的原因， 从而Go的GC的崩溃输脱险些不可提供有用的信息匡助开采者定位问题. 像前述的issue#44614从Go1.14便出手出现， 直至Go1.17发布前才被竖立， 影响了Go1.14.x、Go1.15.x、Go1.16.x这 3 个大版块.

图 1 社区中 Go 逃遁无理联系 issues (空虚足统计) 图 2 社区中Go逃遁无理联系issues数目变化趋势

针对Go 关节和/或Go言语编译器的破绽检测， 面前多网络在对Go关节的并发、竞争检测方面[17−19]， 与Go言语编译器的逃遁分析联系的连接历历， 仅有Wang等东谈主的劳动[20]使得一些对象不错绕过Go言语编译器的逃遁分析， 从而简约堆内存的使用. 面前尚无联系劳动来寻找经Go言语编译器编译出的代码中的无理内存援用， 学术界对此的连接缺失. 同期， 面前Go官方对逃遁分析正确性的测试技能也较为有限， 难以扶持开采东谈主员对逃遁分析算法进行进一步的优化或重构.

为了有用检测编译器生成的代码是否存在可能引起运行时崩溃的犯科内存援用， 在居品上线前就能实时发现问题， 幸免居品在执行生产环境中出现崩溃， 酿成亏欠， 也为了扶持开采东谈主员对内存优化联系算法， 如逃遁分析进行优化和重构， 考据算法的正确性， 本文提议一种衔尾静态分析和动态插桩检测Go二进制中可能导致犯科内存援用的store提示的方法， 并基于 Pin[21]达成了器具原型DBI-Go， 它不错在不修改Go 编译运行时系统的情况下对Go二进制关节进行检测， 具有较好的适用性. 该器具衡量静态分析和动态插桩， 并衔尾 Go 的言语特点， 大大减少了误报率和插桩带来的额外支出.

本文的主要孝顺点包括以下内容.

• 对Go二进制关节进行抽象， 并基于此抽象分析提议两条判定犯科内存援用的判定例则. 犯科内存援用由二进制关节中将不当的地址通过store提示写入: (1) 将栈地址存入栈外; (2) 将较浅栈帧中的对象的地址存入较深栈帧.

• 提议了DBI-Go——第1个使用动态二进制插桩方式分析Go二进制中潜在犯科内存援用的器具. DBI- Go不错将Go的二进制可履行文献与Go语义以及Go的运行时管理系统关联起来， 有着较低的误报率， 且在大多数情况(93.3%)有不进步2倍的额外运行时支出. DBI-Go还不错精确给出违例的发生位置， 匡助快速定位问题.

• 实验遣散标明， DBI-Go不错检测出Go社区中通盘已知的逃遁联系issue， 有着较高的破绽笼罩率. 同期DBI-Go还发现了一个面前Go社区未知的问题. 该问题也曾在golang-nuts中得到 Go官方负责东谈主员的阐述(https://groups.google.com/g/golang-nuts/c/YZVFzwnPixM)， 并已向社区提交issue有待Go官方的进一步竖立(https://github.com/golang/go/issues/61730).

• 对DBI-Go的执行应用还标明， 其不错扶持开采东谈主员对Go逃遁分析算法进行优化和重构， 匡助找到新逃遁分析算法的无理.

本文第1节先容Go逃遁分析及近况， 引出连接动机. 第2节主要对Go二进制进行抽象并提议两条判定例则. 第3节先容DBI-Go的打算挑战以过头最终的打算与达成， 包括其是怎么复原Go二进制上的运行时信息和语义信息及怎么减少误报和镌汰支出. 第4节对DBI-Go的破绽笼罩率、误报率以及带来的额外支出进行实验评估. 第5节对DBI-Go的局限性进行盘考. 第6节先容联系劳动. 第7节进行追思与估量.

1 联系基础与连接动机

本节简要先容 Go 言语的运行时系统和逃遁分析， 并衔尾社区issue概述了面前Go逃遁分析的近况， 说明了面前对逃遁分析正确性考据的不及， 引出本文的连接动机.

1.1 Go的运行时系统与逃遁不变式 1.1.1 Goroutine过头栈管理

Go 言语使用协程 Goroutine[22] 作为 Go 关节的履行高下文. Goroutine 是轻量级的用户态线程， 与由操作系统成功调养的操作系统级线程Thread不同， Goroutine 的调养是由Go 的运行时系统进行管理的. 每个 Goroutine 都有我方专有的栈， 但它的额外支出和默许栈大小都比线程小好多. 与操作系统线程的栈不同， Goroutine 的栈是 Go 运行时系统使用堆内存来模拟的. Go 运行时系统从操作系统请求堆内存后会长期合手有， 再通过其里面的内存分派器按照一定的计谋和时机从中分手出部安分存用于模拟Goroutine的栈.

图3默示了Go 运行时系统对每个Goroutine 的栈管理结构， 其中stack结构包含两个字段: lo和hi， 分别泄露栈的低地址和高地址范围， 它们形容一个栈的内存地址范围位于 [lo， hi) 之间. 每个 Goroutine 在 Go 运行时系统顶用一个g类型的对象泄露， g对象的前几个字段形容它的履行栈， 包括一个类型为stack的字段， 用于形容该 Goroutine 的栈的地址范围. Go 的运行时系统会在 Goroutine 的栈空间不实时进行栈扩展. 当发生栈扩展时， Go 运行时会进行栈拷贝， 将旧栈的内容复制到新分派的栈， lo和hi也会进行相应的编削， 因此 Go 关节履行时间， 每个 Goroutine 的栈并非固定在内存中的并吞段连气儿空间保合手不变.

图 3 Goroutine 履行栈管理默示 1.1.2 Go的垃圾回收与逃遁不变式

Go 言语内存管理主要依赖于其运行时系统， Go 从操作系统请求内存后会长期合手有， 将其分为 Goroutine栈(如前文所述)和Go堆进行管理. Go 堆使用TCMalloc[6]进行快速的并发分派， 并通过Go的并发垃圾收罗(GC)[23]达成堆空间的回收. Go 中的堆对象会使用诸如 runtime.newobject 等运行时函数在 Go 堆上自动分派.

这种内存管理机制使得Go 关节员无需了解一个变量是分派在栈上照旧堆中[24]. Go 向关节员保证， 关节履行的任何时刻中， 肆意由垃圾回收标记算法标记可达的对象都处于人命周期内， 即， 不可能出现吊挂指针. 作为 Go 编译活水线上的一个紧迫优化遍， Go 的逃遁分析用于决定一个对象是堆分派照旧栈分派. 为了内存安全以及 GC 的平常运行， Go 的打算者提议了以下两条逃遁不变式[25].

• 逃遁不变式1: 指向栈对象的指针不可存储在堆中.

• 逃遁不变式2: 指向栈对象的指针人命期不可超出该栈对象.

Go 的逃遁分析在决定对象是堆分派照旧栈分派时必须撤职上述不变式. 逃遁分析若发现存对象违背上述不变式(即违例)， 则该对象会被堆分派. 如代码 1所示， 其中 heapObj 是堆对象， 其在第 5 行援用了 i 的地址. 因此凭证逃遁不变式 1: “指向栈对象的指针不可存储在堆中”， i 需要堆分派. 在代码 2中， ptr 在第 6 行援用了 x 的地址. ptr 在外层轮回声明， x在内层轮回隐式声明， ptr的人命期长于 x. 因此凭证逃遁不变式 2: “指向栈对象的指针人命期不可超出该栈对象”， x需要堆分派.

代码1. 逃遁不变式1示例.

1. //堆对象获取了i的指针导致i被堆分派

2. func heapAssignment() {

3. 　heapObj := newobj()

4. 　i := 1

5. 　heapObj.a = & i

6. 　use(heapObj)

7. }

代码2. 逃遁不变式2示例.

1. //ptr援用x， ptr轮回深度小于x， 人命期长于x， x堆分派

2. func loop() {

3. 　var ptr *int

4.　 for i := 0; i < 5; i++ {

5. 　　x := i

6. 　　ptr = & x

7. 　}

8.　 use(ptr)

9. }

逃遁分析必须正确地决定对象的分派位置， 若有对象的分派位置违背了上述两个逃遁不变式之一， 即存在犯科内存援用， 则会导致 Go 关节运行时的极度步履以致导致运行时崩溃 (panic)， 在执行应用环境中酿成较大亏欠.

1.2 Go 逃遁问题近况 1.2.1 Go 社区中逃遁类联系问题频发

在社区issue 中， Go 的逃遁问题频发， 且每次出现的问题都是致命问题. 近几年出现的联系 issue 的空虚足统计可见图1. 这些 issues 有的是因为逃遁分析算法的无理导致， 有的是因为逃遁分析和其他编译优化的无理合营导致. 底下将通过这些 issue 中的两个典型例子来进行说明.

• 逃遁分析算法的无理. 逃遁分析算法的无容许成功导致一些对象的分派位置出错. 以issue#44614 [15]为例， 其一个简化版的实举例代码3所示. 在该例子中， 对象r由于被全局变量sink援用而被堆分派. 函数global2stack中的参数p， 在return p语句中被堆对象r获取， 因此通盘传给global2stack的指针理当被标记为逃遁， 但由于逃遁分析的破绽， 逃遁分析在分析global2stack函数时以为参数p莫得逃遁. 这就导致了在代码 3中， 地址被传给global2stack的变量i理当被堆分派， 但却被逃遁分析无理地以为应该栈分派.

代码3. issue44614简化版示例.

1. var sink interface{}

2. func global2stack(p *int) (r *int) {

3. 　sink = & r

4. 　 return p

5. }

6. func g2s() {

7. 　i := 1 //i应该堆分派， 却被无理地栈分派

8.　 j := global2stack(& i)

9. 　_ = j

10. }

• 逃遁分析和后续编译优化的无理合营. 未必诚然逃遁分析莫得出错， 但后续的一系列的编译优化却可能酿成无理. 一个例子是社区issue#54247 [14]. 其一个简化版的实举例代码4所示. 在该例中， obj1是栈对象， 但逃遁分析后续编译进程中对defer的处理导致函数Recover的参数objs逃遁到堆上， 这就导致在第 4 行， 栈对象obj1的地址被堆对象objs获取， 违背逃遁不变式， 导致无理.

代码4. issue54247简化版示例.

1. func Escape(task func()) {

2. 　var obj1 obj

3. 　defer Recover(

4. 　　& obj1，

5. 　) //obj1应该堆分派， 却被无理地栈分派

6. 　task()

7. }

8. func Recover(objs ...*obj) {

9. 　　 use(objs)

10. }

由于这些对象分派位置出错， 因此援用这些对象的堆和全局对象极易出现吊挂指针. Go 向关节员保证， 关节履行的任何时刻中， 肆意可达的对象都处于人命周期内， 即， 不可能出现吊挂指针. 当Go 的GC 遭逢吊挂指针时会成功在运行时panic， 使得通盘这个词Go 关节极度圮绝. 若在执行生产环境中出现该问题， 则很有可能带来不可赈济的亏欠. 同期， GC 不是发生这种无理的第一现场， 以代码 3为例， 其发生无理的第一现场应是第 4 行的return p， 在该处栈对象的地址被传递给堆对象. 因此， GC的panic具有延后性和不可先见性. 由于 GC 不是无理的第一现场， 其崩溃输出多和 GC 联系而和事发的第一现场无关. 后文图4所示为issue#44614和issue#54247中的崩溃输出. 其多为炫夸 GC 的劳动进程和情状信息， 不可准确地炫夸栈对象是在什么位置被传递给了全局或堆对象. 不无缺的信息也给排查问题带来了艰辛， issue#44614中逃遁分析的破绽从Go1.14 出手出现， 直至 Go1.17 发布前才被竖立， 影响了 Go1.14至Go1.16这3 个大版块.

图 4 崩溃输出示例 1.2.2 逃遁分析正确性考据的近况

Go 言语官方对逃遁分析正确性的考据技能也较为有限， 面前在 Go 言语官方给出的逃遁分析的测试中对逃遁分析正确性的考试存在比较函数复返值和比较 DeBug 信息这两种阶梯.

阶梯一[26]是通过查验两次调用并吞个函数的复返值是否沟通来判断逃遁分析正确性的. 在这个函数里面会为一个对象分派一块空间， 这部分空间理当堆分派， 这么在两次函数调用中将该空间的地址复返时为不同的地址， 这就不错通过测试. 但是如果该空间由于无理的逃遁分析导致被栈分派， 因为栈帧的布局在编译完成后也曾详情， 故将导致在并吞个栈帧下两次调用该函数复返的该变量的地址将为沟通的地址， 这么就不可通过测试. 这种情况只可适用于小限制测例， 而且条款在并吞个栈帧下调用沟通函数进行测试， 较难蔓延.

另外一种阶梯[27]是通过标注的方式来进行查验的. 通过将预先东谈主工标注的信息以及逃遁分析在debug模式下打印输出的信息进行比对来考据逃遁分析算法的正确性.

这两种阶梯从执行上来讲都是通过标注测试的方式来达成的， 需要预先东谈主工分析Go 关节并进行标注， 其无法用于考据执行应用关节中预先未知的无理.

此外， Go的运行时系统在GC时会考据对象的指向是否有错， 但该方法的范围有限. 领先， 并不是通盘无理的指向都能被GC发现. 其次， 该考据机制将无理的指向延伸到GC时才进行检测， 不可实时发现问题， 且GC一朝发现问题会成功panic， 酿成通盘这个词关节的崩溃， 可能在执行生产环境中酿成不可弥补的亏欠. 临了， GC的崩溃输出较难线路， 难以匡助开采东谈主员定位问题的发生位置， 为后续排查劳动带来未便.

总之， Go面前测试和考据方法十分有限， 在执行应用关节中发生无理时， 现存方法无法用于定位发生无理的位置以及发生无理的原因. 图1中的种种issue也印证了Go现存方法的局限性.

1.3 连接动机

传统的内存联系破绽的寻找劳动多网络于C/C++关节的二进制[28−30]. 但由于Go关节有额外的运行时管理机制以及额外的语义， 传统基于C/C++的劳动并不可成功应用在Go二进制上. 面前学术界在Go关节的破绽寻找上有不少劳动， 但这些劳动多网络在并发、数据竞争联系的破绽寻找上[17，18，31]. 面前衰退考据Go编译器生成的代码是否安闲Go逃遁不变式的连接.

怎么保证Go编译器中逃遁分析的决策遣散以及经过其他编译器优化遍之青年景的代码仍然合乎逃遁不变式瑕瑜常紧迫的. 可是， 正如第 1.2 节所述， Go 面前逃遁联系issue 频发且无较为有用的测试技能， 且现存联系连接缺失. 为了有用处分这类问题， 确保经过逃遁分析和一系列优化遍青年景的二进制可履行文献中莫得违背 Go 逃遁不变式的情况， 研制一个不错有用检测执行应用中违背 Go 逃遁不变式情况的器具是很有必要的.

2 Go关节逃遁不变式违例的判定例则

本节对 Go 关节进行抽象， 随后衔尾 Go 的逃遁不变式抽象出 Go 关节中违背逃遁不变式的判定例则.

2.1 Go 关节抽象

凭证 Go 的文档[23，32]， Go 应用关节的内存由全局数据区、受 GC 管理的 Go 堆区、每个 Goroutine 的栈区构成. 基于此， 咱们将一个 Go 关节的内存分为3部分: Goroutine栈、Go堆区以及Go全局数据区， 并提议如公式(1)所示的抽象. 通盘这个词宇宙$\mathbb{W}$由一个含有n个Goroutine的集结$\mathbb{GS}$、一个Go堆区$\mathbb{GH}$、一个Go 全局数据区$\mathbb{GG}$构成. 每个Goroutine $\mathbb{G}$由运行在其上的用户代码$\mathbb{C}$以及对应的Goroutine栈$\mathbb{S}$构成. $\mathbb{GH}$、$\mathbb{GG}$、$\mathbb{S}$均是内存地址的集结， 其中: $\mathbb{GH}$和 $\mathbb{GG}$分别记载Go关节在用的有用堆地址和全局数据区地址; $\mathbb{S}$是Goroutine的栈地址， 由从addrlo到addrhi的连气儿内存地址构成. $\mathbb{C}$是一个提示列表， 由于这里只负责潜在引起Go逃遁不变式违例联系的提示， 因此提示列表中只包含触及存储指针的store提示和可能引起放荡流变化的cmp和br提示. 其中提示store addrdst， addr代表将addr存入 addrdst所指向的内存区域.

$ \begin{array}{lllll} { (\mathrm{World}) } & \mathbb{W} & ::= & \left(\mathbb{G} \mathbb{S}， \mathbb{G} \mathbb{H}， \mathbb{G}{\mathbb{G}}\right) \\ { (\mathrm{Goroutine} \;\mathrm{set}) } & \mathbb{G} \mathbb{S} & ::= & \left(\mathbb{G}_1， \mathbb{G}_2， \ldots， \mathbb{G}_n\right) \\ { (\mathrm{Go}\; \mathrm{heap}) } & \mathbb{G} \mathbb{H} & ::= & \text { \{addr\} } \\ { (\mathrm{Go}\; \mathrm{global}) } & \mathbb{G} \mathbb{G} & ::= & \text { \{addr\} } \\ { (\mathrm{Goroutine}) } & \mathbb{G} & ::= & (\mathbb{C}， \mathbb{S}) \\ { (\mathrm{Code}) } & \mathbb{C} & ::= & \text { [instr] } \\ { (\mathrm{Goroutine}\; \mathrm{stack}) } & \mathbb{S} & ::= & {\left[\operatorname{addr}_{\mathrm{lo}}， \mathrm{addr}_{\mathrm{hi}}\right)} \\ { (\mathrm{Memory}\; \mathrm{address}) } & \text { addr } & ::= & \text { n (unsigned nums) } \\ { (\mathrm{Instruction}) } & \text { instr } & ::= & \text { store } \operatorname{addr}_{\mathrm{dst}} \text {， addr } \\ &&&\text { | br addr | cmp } \end{array} $ (1) $ \begin{array}{rll} {code}(\text { instr }) & \stackrel{\text { def }}{=} \mathbb{C} & \text { instr } \in \mathbb{C} \\ {code}G\left(\mathbb{C}_0\right) & \stackrel{\text { def }}{=} \mathbb{G} & \mathbb{G} \cdot \mathbb{C}==\mathbb{C}_0 \\ {codeS}(\mathbb{C}) & \stackrel{\text { def }}{=} \mathbb{S}_0 & \mathbb{S}_0=={code}G(\mathbb{C}) . \mathbb{S} \end{array} $ (2) 2.2 违背 Go 逃遁不变式的判定例则

为便于形容， 领先引入一些扶持函数， 界说见公式 (2). 其中code(instr)用于获取提示instr场所的提示序列$\mathbb{C}$， codeG($\mathbb{C}$)用于获取履行提示序列$\mathbb{C}$的Goroutine， codeS($\mathbb{C}$)用于获取履行提示序列$\mathbb{C}$的Goroutine栈.

为了背面盘考违背逃遁不变式的判定例则以及栈对象的人命期， 接下来界说两个主张.

界说1 (分歧法的 store提示). 若一条store 提示 sl: store addrdst， addr的内存拜谒违背了 Go 逃遁不变式， 则将其记为$ illegal\left({s}_{l}\right) $.

界说2 (栈对象场所的栈帧深度). 若addr为某栈对象地址， 则$ fd\left(\mathrm{addr}\right) $代表addr 指向的栈对象场所的栈帧深度. 处于栈顶的函数栈帧深度为 1， 其余函数的栈帧深度沿着栈上的调用链轮番加 1. 越围聚栈顶的栈帧， 其栈帧深度越小.

凭证第 1.1 节所述的两条Go逃遁不变式， 可得违背Go逃遁不变式的情况为:

• 违背逃遁不变式1: 栈对象指针被堆对象获取.

• 违背逃遁不变式2: 栈对象指针被人命期更长的对象获取.

针对违背逃遁不变式 1 的情况， 其表现为堆对象指向了栈对象， 栈对象地址在某处被存入堆对象中. 因此， 针对提示 sl: store addrdst， addr ， 可用公式(3)来判断是否违背了逃遁不变式1， 即 addrdst 是堆地址且addr 是现时履行提示sl场所的Goroutine栈中的地址时， 提示sl会因引起逃遁不变式的违例而视为分歧法.

$ \frac{\mathbb{S}={codeS}\left({code}\left({s}_{l}\right)\right)\qquad\mathrm{addr}\in \mathbb{S}\wedge \text{addr}_{\text{dst}}\in \mathbb{G}\mathbb{H}}{illegal\left({s}_{l}\right)} $ (3)

针对违背逃遁不变式 2 的情况， 比现时栈对象人命期更长的对象可能有多种情况， 包括堆对象、全局对象、其他 Goroutine 的栈对象， 以及现时 Goroutine 的栈对象. 前3种情况都以为是现时 Goroutine 栈除外的对象. 底下分别进行盘考.

• 将栈对象地址写入现时 Goroutine 栈除外的违例情况. 除了公式(3)盘考过的堆对象外， 通盘全局对象都可以为比现时栈对象人命期更长. 此时表现为全局对象指向了栈对象， 栈对象地址在某处被存入全局变量中. 因此， 针对提示 sl: store addrdst， addr， 可用公式(4)来判断是否将栈地址存入全局变量中.

$ \frac{\mathbb{S}={codeS}\left({code}\left({s}_{l}\right)\right)\qquad\mathrm{addr}\in \mathbb{S}\wedge \text{addr}_{\text{dst}}\in \mathbb{G}\mathbb{G}}{illegal\left({s}_{l}\right)} $ (4)

由于不同Goroutine的履行受Go运行调养的影响可能相互交叠， 分处在不同Goroutine栈中的栈对象人命期可能存在交叠， 也可能存在不祥情的一先一后， 因此将现时Goroutine中的一个栈对象的地址存到另一个Goroutine栈中亦然不安全的. 为此， 针对提示 sl: store addrdst， addr， 可用公式(5)来判断是否将现时 Goroutine 中的栈地址存入了另一个Goroutine栈中.

$ \frac{\mathbb{S}={codeS}\left({code}\left({s}_{l}\right)\right)， {\mathbb{G}}_{1}={codeG}\left({code}\left({s}_{l}\right)\right)\qquad\exists {\mathbb{G}}_{2}， \mathrm{addr}\in \mathbb{S}\wedge \text{addr}_{\text{dst}}\in {\mathbb{G}}_{2}.\mathbb{S}\wedge {\mathbb{G}}_{1}\ne {\mathbb{G}}_{2}}{illegal\left({s}_{l}\right)} $ (5)

由于Go的地址空间由Go 堆、全局数据区， 以及通盘Goroutine的栈构成， 因此， 一个对象若不在现时 Goroutine栈中， 则要么在 Go 堆中， 要么在全局数据区， 要么在其他 Goroutine 栈中. 即:

$\left\{ \begin{array}{l} \mathbb{S}={codeS}\left({code}\left({s}_{l}\right)\right)， {\mathbb{G}}_{1}={codeG}\left({code}\left({s}_{l}\right)\right)\\ \text{addr}{}_{\text{dst}}\notin \mathbb{S}\iff \text{addr}_{\text{dst}}\in \mathbb{GH}\vee \text{addr}_{\text{dst}}\in \mathbb{GG}\vee \left(\exists {\mathbb{G}}_{2}， \text{addr}_{\text{dst}}\in {\mathbb{G}}_{2}.\mathbb{S}\wedge {\mathbb{G}}_{1}\ne {\mathbb{G}}_{2}\right) \end{array} \right.$ (6)

衔尾公式 (6)， 可将公式 (3)、公式 (4)、公式 (5) 合为一个式子， 此时便得到判定违背逃遁不变式的第1条功令， 该功令揭示了栈对象地址被写入现时 Goroutine 栈除外的内存使用违例情况.

功令1. 栈对象地址被写入现时Goroutine栈除外的违例判别.

$ {s}_{l}:store\text{addr}_{\text{dst}}， \mathrm{addr} $ $ \frac{\mathbb{S}={codeS}\left({code}\left({s}_{l}\right)\right)\qquad\mathrm{addr}\in \mathbb{S}\wedge \text{addr}_{\text{dst}}\notin \mathbb{S}}{illegal\left({s}_{l}\right)} .$

该功令泄露将现时Goroutine栈的对象地址存入现时Goroutine栈外， 导致栈外对象援用栈内对象是不合乎Go的逃遁不变式条款的， 如图5(a)所示.

图 5 功令1及功令2默示

• 将栈对象地址写入现时 Goroutine 栈内的违例情况. 在并吞个 Goroutine 栈中， 不同栈对象人命期亦有差距， 比如作用域较浅的栈对象比作用域深的栈对象人命期长， 较深函数栈帧中的栈对象比较浅函数栈帧中的栈对象人命期长. 由于在二进制中也曾难以看到源代码层级的作用域， 此处只可通过栈对象场所函数栈帧的浅深来判断其人命期， 以为较深栈帧栈对象人命期更长， 如图5(b)所示. 由此不错引出判定违背逃遁不变式的第2条判定例则， 即功令2.

功令2. 栈对象地址被写入现时 Goroutine 栈内的违例判别.

$ {s}_{l}:store\text{addr}{}_{\text{dst}}， \mathrm{a}\mathrm{d}\mathrm{d}\mathrm{r} $ $ \frac{\mathbb{S}={codeS}\left({code}\left({s}_{l}\right)\right)\qquad\mathrm{addr}\in \mathbb{S}\wedge \text{addr}_{\text{dst}}\in \mathbb{S}\wedge fd\left(\mathrm{addr}\right) < fd\left(\text{addr}_{\text{dst}}\right)}{illegal\left({s}_{l}\right)} .$ 3 DBI-Go 的打算与达成

本节将先容DBI-Go， 一款用于识别Go二进制中写入指针的store 提示并在运行时考据其是否违背Go逃遁不变式的器具的具体打算与达成.

3.1 打算标的和打算念念路

DBI-Go的打算标的主要包括以下几点.

• 轻量快速. 该器具应该尽可能轻量化， 不错以较快的速率分析出遣散， 提高效率.

• 适用性强. 该器具应该尽可能孤独于Go的编译器具链， 不错相沿不同Go版块编译器生成的二进制， 相沿在未修改编译运行时的原生Go二进制上进行检测.

• 低误漏报. 有用镌汰误报率不错大大减少东谈主工筛选破绽的时候. 同期， 减少漏报率不错确保该器具不错有用发现潜在的破绽.

为达到上述打算标的， 对DBI-Go的打算的主要念念路是衔尾Go言语的特点来快速原型化. 通盘这个词打算中的枢纽主要荟萃于两点: (1)关节分析方式的遴荐; (2)怎么衔尾并利用第 2 节抽象并追思出的违例判定例则.

• 分析方式的遴荐. 面前学术界也曾开采了多种器具[17，18，33，34] 来识别Go应用关节中的种种破绽， 主要使用两种分析时刻——静态分析和动态分析. 静态分析无需履行即可分析Go源代码. 可是， 静态分析在识别方面的笼罩范围有限. 此外， 由于不精确的指针分析， 静态分析可能会引入许多误报或漏报. 当在执行的 Go 应用关节中进行大范围分析时， 这种不精确性会飞快蕴蓄. 因此， 单纯的静态分析难以安闲DBI-Go的低误漏报的打算标的.

现存的动态分析通过额外的运行时信息监视Go关节的履行， 不错减少误报和漏报. 但是这些动态方法需要修改Go编译器或运行时来收罗必要的数据， 与Go的编译运行时强耦合. 当Go的编译运行时发生改变时， 这些动态方法很容易失效. 这种条款很大程度上圮绝了这些器具在执行生产环境中的Go应用上的使用， 也不合乎DBI-Go的适用性强的打算标的.

在 Go 应用关节的二进制代码上进行为态分析不错开脱这些问题， 既不错在运行时监视 Go 关节的履行， 又无需修改 Go 的编译运行时. 因此， DBI-Go 以动态二进制插桩作为主要的分析方式.

• 怎么利勤劳令1和功令2. 详情了关节分析方式之后， 就不错入辖下手打算DBI-Go. 第2节抽象追思的功令1和功令2仅提供了判定的表面. 若要使勤劳令1和功令2， 通过不雅察其气象， 不难发现， 在二进制代码上使用该功令必须谈判以下两个枢纽问题.

(1) 怎么识别存储指针的提示store addrdst， addr: 这类提示改变内存之间的援用关系， 潜在可能抵抗逃遁不变式.

(2) 怎么获取 Go 运行时Goroutine的栈信息: 由第1.1.1节可知， Go 关节履行时间 Goroutine 的栈地址区间不是一成不变的， 因此需要有阶梯准确获取现经常刻的栈信息.

这两个枢纽点亦然关节分析的难点. 第 3.2 节将先容使用静态分析识别写入指针的store 提示的挑战以及咱们的处分决策. 第 3.3 节将先容怎么从较为顽固的 Go 运行时中获取 Go 关节运行时 Goroutine 的栈信息.

DBI-Go 的举座架构如图6所示. DBI-Go 主要由两个组件构成.

图 6 DBI-Go举座架构

(1) StoreFinder: 它使用静态分析索取 Go 二进制关节中存入指针的 store 提示， 并在二进制代码上插桩 (第 3.2 节).

(2) StoreValidator: 它以运行时回调函数的气象识别违背 Go 逃遁不变式的内存援用破绽， 并输出无理日记信息， 便于开采者定位无理(第 3.3 节).

DBI-Go 基于Pin[21] 打算达成了上述两个组件， 包括约1000行C++代码. Pin是由Intel开采的相沿IA-32、X86-64和MIC提示集架构的动态二进制插桩框架， 可用于达成动态关节分析器具.

3.2 使用静态分析从Go二进制中复原Go的store指针语义

Go 是编译型言语， Go 关节一朝被编译运动后其二进制代码中通盘提示都会固定下来. 因此， 不错通过静态分析的方式识别 Go 关节二进制代码中的 store 提示. 可是， 若要判定一条 store 提示是否在存储指针(即功令1和功令2中的store addrdst， addr气象)， 就还需要获取 Go 关节的一些高层语义信息， 如类型等. 底下先分析难点， 然后给出处分念念途经头枢纽点的达成方法.

3.2.1 难点分析及处分念念路

凭证Zeng[35] 的劳动， 在C 言语的二进制中， 通盘高等类型信息， 如整型、浮点型和指针类型， 在编译后都会丢失， 二进制代码中仅有的两种类型是寄存器和内存位置. 在Go 言语中也雷同， Go 二进制关节也曾难以区分指针类型和非指针类型.

• Go二进制中指针的识别难点. Go言语中， 指针类型用于传递对象地址， 不可进行指针运算. Go的GC会扫描指针， 堆指针指向的对象会在合适的时机被GC回收. 可是， Go言语中有一种类型 uintptr[36]， 其大小和平庸指针沟通， 不错容纳肆意的指针类型的值， 不错用于进行指针运算等操作. 但GC并不把uintptr 手脚指针， 因此也不会基于该指针值进行对象标记. 若把某栈对象的指针转为 uintptr 后存入堆对象， 并在之后欠亨过它拜谒对象， 那么这种存入操作并不违背Go的逃遁不变式， 因Go并不将uintptr视作指针. 可是， Go二进制中仅有的两种类型是寄存器和内存位置， 难以判断某个寄存器或者内存位置中的值是指针照旧 uintptr. 若对其不作念区分， 都视为指针， 则例必会带来好多误报， 影响精度和效率.

• Go二进制中地址存入操作的识别难点. 除了类型信息的缺失， Go二进制上的地址存入操作与用户代码中的地址存入操作也有较大远隔. Go编译器在编译Go关节时会履行若干关节变换， 在用户代码中生成诸多与Go运行时管理联系的代码， 以便Go运行时系统对Go关节的管理. 在这些代码中会产生若干违背Go逃遁不变式store操作， 但Go的运行时保证了这些操作的安全性. 若不将这些操作撤销， 也会带来较多的误报.

• 处分念念路. Zhong 等东谈主[17] 通过Go运行时系统中管理并发的联系函数复原了Go二进制上的并发语义. 这启发咱们不错通过静态分析的方式， 识别Go二进制用户代码中庸内存管理、垃圾回收联系的Go运行时函数来复原联系的store指针的语义. 经过对Go运行时联系函数的分析可发现， Go运行时和写樊篱联系的运行时函数不错用来复原相应的store 提示. 第3.2.2节中先容该机制， 并在第3.2.3节中先容怎么使用该机制来复原安闲条款的store提示并使用Pin API为其注册运行时的回调函数.

3.2.2 Go的写樊篱

Go运行时的不可或缺的部分为垃圾回收(GC)系统. 尽管GC在幕后运作， 却少见个运行时函数与其息息联系. 这些运行时函数分为两类: 一部分可供用户主动调用， 用于配置GC参数或强制启动新的GC 周期; 另一部分由编译器在编译时间自动插入， 在运行时扶持GC的运行， 确保GC联系内存情状的准确性. 在这个体系中， 编译器自动插入的runtime.gcWriteBarrier函数在负责GC联系内存情状的正确性方面饰演着枢纽脚色.

Go的GC系统在堆内存使用达到特定阈值时会中断用户关节的运行， 对那些由根网络的指针成功或障碍可达的对象进行扫描和标记， 标记出仍在人命周期中的对象， 随后开释也曾不再使用的对象. 在这个过程中， 用户关节填塞暂停， 因此在逻辑上对GC的发生莫得感知， 这确保了内存读写不会对GC情状酿成任何关扰.

Go的并发GC在特定阶段允许用户关节与其并行， 以减少恭候时候. 可是， 在GC对对象进行标记的过程中， 用户关节的内存读写可能会修改对象的援用关系， 这可能导致GC的标记与执行情况不一致， 从而无理地计帐正在使用的对象. 举例， 如果在GC完成对栈指针的扫描后， Go应用关节将某个堆对象的地址存入栈对象中， 而这个新援用关系的创建莫得被 GC 感知到， 即该堆对象莫得被 GC 标记， 那么在这一轮GC遣散后， 该栈对象合手有了一个也曾被开释的堆对象地址， 从而导致内存无理. 因此， 在GC运行时间， GC需要获知通盘指针类型的内存写入， 以查验这些在运行过程中发生改变的援用关系. 在 Go 关节中， 如果一个 store 操作可能存入指针类型， 则Go编译器会在编译时间在该store操作周围生成特定的放荡流， 插入 runtime.gcWriteBarrier函数， 该函数在GC时会汲取相应的store操作， 并负责匡助GC 负责正确的内存援用关系.

Go 编译器只会对用户代码中包含指针的 store 操作插入 runtime.gcWriteBarrier， 且不会对一些可能带来误报的运行时函数中的 store 操作插入该函数. 若大概在二进制中识别相应的结构， 就能复原 Go 的 store 语义， 大大收缩由于 Go 运行时、非指针 store 等带来的误报问题， 同期还大概减少好多对不必要的 store 插桩， 收缩动态二进制插桩带来的额外支出.

3.2.3 利用 Go 的写樊篱机制复原store指针的语义

编译生成的与runtime.gcWriteBarrier联系的汇编级放荡流模式如图7所示. 由于编译器在编译时在store周围插入的特定放荡流有固定的结构， 是以其临了生成的二进制中围绕runtime.gcWriteBarrier也有特定的结构. 将这些特征追思抽象， 不错形成图7中的特定放荡流模式， 以便后续精确识别.

图 7 编译生成的gcWriteBarrier联系放荡流

咱们提议算法1来识别Go二进制中该特定的放荡流模式. 其主要念念路在于通过寻找特定的cmpl提示来详情安闲条款的基本块bb1， 再通过bb1中的放荡流跳转语句(JNE)来详情安闲条款的两个后继基本块bb2和bb3， 条款bb2和bb3有且仅有一个沟通的后继.

算法1. 识别图7中的放荡流并为其中安闲store 指针语义的提示建立回调函数.

输入: Go 二进制文献Bin;

输入: Bin中全局变量runtime.writeBarrier的地址wb.

运行遣散: 识别出Bin中安闲Go的store语义的提示， 并为其在Pin中注册运行时的回调函数

1. FOR ALL instr in Bin DO

2. 　IF instr.opcode==cmpl THEN

3. 　　IF instr.operands[0]==0 且 instr.operands[1]的有用地址 == wb THEN

4.　　　 j=instr之后最近的jne提示， 且该 jne之前莫得其他跳转提示

5. 　　　bb3=BB(j.target)　 j的方针地址处的基本块

6. 　　　bb2= BB(j.next)　 j的下一条提示处的基本块

7. 　　　IF len(successors(bb2))==1 且 successors(bb2)==successors(bb3) THEN

8. 　　　　FOR ALL s:store in bb2 DO

9. 　　　　　在store提示s前注册运行时回调函数

10.　 　　　END FOR

11. 　　　　FOR ALL c:call in bb3 DO

12.　　　　　 IF c.targetFunc以runtime.gcWriteBarrier为前缀 THEN

13. 　　　　　　识别call提示c的参数

14. 　　　　　　在call提示c前注册运行时回调函数

15. 　　　　　END IF

16. 　　　　END FOR

17. 　　　END IF

18.　　 END IF

19. 　END IF

20. ENDFOR

在算法1中， 基本块bb2中的通盘store提示被以为都可能存储指针， 并将这些store转为功令1和功令2接受的气象: store addrdst， addr. 之后， 通过使用 Pin 的API为这些store提示注册运行时回调函数. 在关节适值运行到这些store提示之前时， 注册的回调函数会被履行用来检测其是否违背了Go逃遁不变式.

关于基本块bb3， 它对应在GC时间调用runtime.gcWriteBarrier函数来汲取store. 因此， 不错在bb3中识别runtime.gcWriteBarrier所需的参数(即图7中所示的ptr和val). 在达成中发现， Go编译器为了优化调用runtime.gcWriteBarrier的进程， 减少准备参数的支出， 为runtime.gcWriteBarrier函数生成了不同版块， 这些不同的版块惟一传参的寄存器有区别. 比如runtime.gcWriteBarrierR9函数， 比较于原版的runtime.gcWriteBarrier， 参数val使用寄存器R9来进行传递， 其余进程均与runtime.gcW-riteBarrier沟通. 为此， 不错识别runtime.gcWriteBarrierRXX的后缀来判断其传递val参数的寄存器. 当识别出runtime.gcWriteBarrier的参数后， 就可将其转为store addrdst， addr的气象(ptr 对应 addrdst ， val对应 addr)， 并在call提示前注册运行时的回调函数用于在运行时检测该call 提示所代表的store是否违背了Go逃遁不变式.

3.3 在运行时回调函数中复原 Go 运行时栈信息

Go运行时函数库以静态运动的方式与Go应用代码运动起来形成可履行的Go关节. Go运行时函数负责在运行时管理Go关节运行所需的堆、Goroutine的调养以及Goroutine的栈等. 用户编写代码时无需了解运行时的达成细节， 比如对象怎么分派， Goroutine怎么调养， Goroutine栈怎么管理等. 但是， 如若要在二进制层面分析内存的援用关系， 分析栈对象地址是否被存储到栈外、是否违背逃遁不变式， 这就条款必须大概得到受Go运行时管理的一些信息， 比如现时Goroutine的栈信息等. 可是， Go的运行时管理系统并不像操作系长入样提供了若干API用于在外部获取系统运行时信息. Go的运行时系统相对顽固， 莫得完备的API供外部得到现时Go关节的运行时信息.

运道的是， 咱们隆重到Go言语的ABI表率[32]中界说了一些运行时信息的存储位置， 比如现时的Goroutine， 来供运行时函数使用. 这意味着不错通过在二进制中添加回调函数的方式得到这些运行时信息.

在第3.2.3 节中， 已为安闲条款的store提示注册了运行时的回调函数. 该回调函数需要衔尾运行时信息来使勤劳令1和功令2检测这些store是否违背了Go的逃遁不变式. 第 3.3.1 节将先容该回调函数在运行时怎么利用Go的ABI从Go二进制中得到现时履行提示的Goroutine过头栈的联系信息.

3.3.1 在运行时回调函数中得到 Goroutine 栈信息

由第1.1节可知， Goroutine栈是在操作系统进度的堆内存中模拟， 那么要获知Goroutine栈的范围， 判断某个指针是否是栈指针就不可毛糙地用操作系统的系统栈去判定. 为卓著到Goroutine的栈信息， 需要得到运行时顶用于管理Goroutine的g对象. 之后通过领悟g对象的前几个字段的内存布局即可得到相应Goroutine的栈信息.

诚然Go运行时中的g对象不对用户走漏， 但运道的是， 凭证Go的ABI-Internal[32]的商定可知， 在AMD64 架构中， R14寄存器会保存现时履行的代码场所的Goroutine， 也等于g对象的地址. 再衔尾ABI-Internal中联系基本类型大小和对皆的商定以及前文所述的 g和stack的结构， 不错通过公式(7)得到现时栈的lo、hi:

$ \left\{\begin{array}{l}{\rm{lo}}=\mathrm{*}RE{G}_{R14}\\ {\rm{hi}}=\mathrm{*}\left(RE{G}_{R14}+8\right)\end{array}\right. $ (7)

在利用Go的ABI-Internal得到Go的运行时栈信息时， 咱们发现旧版块的Go (Go1.16.15及以下)的ABI 与较新版块Go (Go1.16.15 以上)现行的ABI-Internal不同. 旧版块Go中， g对象的地址不在寄存器R14 中， 且旧版块的Go并莫得相应的ABI文档. 为显然解怎么得到旧版块Go中的运行时信息， 咱们对旧版块的Go的编译运行时系统进行了东谈主工分析. 最终发当今旧版块Go中， g对象的地址存放在TLS (thread local storage)中的固定位置， 作为线程腹地存储的一部分. 为了区分新版块和老版块的Go， DBI-Go在加载二进制时， 会领先得到系统Go的版块， 凭证Go的版块选用不同的计谋. 针对Go1.16.15以上的Go， 会使用Go 现行的ABI-Internal从寄存器R14中得到g对象的地址. 在Go1.16.15及以下的Go中， 则会从TLS中的固定位置得到g对象的地址， 并随后得到运行时栈信息.

得到相应的栈信息后， 即可检测某地址是否在现时Goroutine栈中， 随后可衔尾功令1和功令2判断该store是否违背Go的逃遁不变式. 若该store违背了逃遁不变式， 就会衔尾该提示的地址得到其场所的函数， 并向log文献中输出相应的出错信息， 包括该提示的地址、场所的函数、违背不变式的原因以及现时的运行时栈信息. 这些信息不错在之后匡助开采者更快地找到问题.

3.4 接纳多种方法减少误报

为了减少误报， DBI-Go主要选用了以下方法.

(1) 方法 1: 过滤掉非Go函数. Go的运行时最终以静态运动库的气象和用户代码运动成可履行文献， 其中除了 Go 函数外还包括许多汇编和C函数. 汇编和C函数不校服Go的ABI商定， 对这些函数进行分析会得到无理的遣散. 同期， 这些非Go函数也不校服Go的逃遁不变式， 因此也无需对其进行分析. Go的代码以包(package)的气象进行管理， 每个函数都有其场所的包. 基于此不雅察， DBI-Go接纳基于模式匹配的方法， 通过函数名判断每个函数是否在某个包内， 并据此过滤掉通盘非Go函数.

(2) 方法 2: 过滤掉 Go 运行时函数. Go除了会在用户代码中生成若干涉运行时管理联系的代码外， 还会使用runtime包中的运行时函数来进走时行时管理. 这些运行时函数会产生若干违背Go逃遁不变式的store操作， 但这些操作由Go的运行时保证了其安全性. 因此在DBI-Go的达成中会过滤掉runtime包中的函数以幸免误报.

(3) 方法 3: 过滤掉非指针store. 利用第3.2.3节中的方法， DBI-Go不错复原Go二进制中store 指针的语义， 过滤掉不包含指针的对象的store. 使用该方法不错大大镌汰将非指针类型诸如int、uintptr等手脚指针从而带来的误报， 提高 DBI-Go的分析精度.

以上方法不仅不错镌汰误报， 还镌汰了 DBI-Go 的举座支出. 通过上述方法， 咱们提高了DBI-Go的精度和分析效率 (详见第4.3节).

4 实验评估

对 DBI-Go 的实验评估在 x86-64 的机器上进行. 实验环境如下所示.

• 操作系统: Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-48-generic x86_64).

• CPU: 2 × AMD EPYC 7763 64-Core Processor.

• 内存: 1.0 TiB.

• 触及的Go版块: Go1.11 至 Go1.20.5.

实验试图恢复以下连接问题.

(1) DBI-Go对已知破绽的笼罩情况怎么， 能否发现新的破绽?

(2) DBI-Go插桩的回调函数带来的额外支出有几许， 是否安闲了轻量快速的标的?

(3) DBI-Go的适用性怎么， 能否在不同的 Go 版块上平常使用?

4.1 有用性测试

为了对DBI-Go的破绽笼罩率进行测试， DBI-Go测试了图1中面前通盘已知的社区例子. 针对图1中面前不错复现且有着复现例子的issue， 咱们使用对应的Go 版块将这些例子编译， 并之后使用DBI-Go插桩. 图1中提供复当代码并可复现的issue共有5个， 分别为issue#29000[37]， issue#31573[38]， issue#44614[15]， issue#47276 [39]和issue#54247[14]. 其触及的Go版块为Go1.11至Go1.17， 年份跨度为2018–2022年. 最终的遣散炫夸， DBI-Go的破绽笼罩率较高， 其不错检测出图1中通盘可复现的例子中的违背Go 逃遁不变式的store提示. 输出的log文献比较于Go原始GC panic时产生的信息不错更澄莹地展示分娩生无理的提示过头场所的函数， 不错匡助更快定位原因. 以issue#44614 [15]为例， 其简化版代码可见代码3. 图8(a)为社区issue 中Go GC的log， 图8(b)为DBI-Go的log. 比较于GC的log， 其不错更精确的炫夸问题的产生地， 比如二进制提示地址以及场所的函数. 若能衔尾DWARF信息， 还不错找到对应的源代码的位置， 更便于问题定位.

图 8 GC log与DBI-Go log

Go的轨范库(std)和编译器具链(cmd)提供了多数测试用例和Benchmark， 笼罩了其中的浩大常用API. Go的轨范库和编译器具链中共有277个包提供了测试用例. 咱们使用最新版块的Go (Go1.20.5)， 将这些测试用例和Benchmark编译成可履行文献， 并随后使用DBI-Go进行检测. 遣散标明， 在这277个包中的276个莫得发现问题， 可是， 在syscall包中， DBI-Go发现Go在处理切片的字面量时将栈上的数组地址存到了全局变量中. 它的简化版示举例图9所示. LEAQ 0x8(SP)， AX提示将栈对象的地址0x8(SP)存入了寄存器AX中， 接下来的MOVQ提示将该栈地址store到了某全局变量处. 该store违背了功令1并被DBI-Go所拿获.

图 9 syscall 包中发现的违背 Go 逃遁不变式的 store

面前该问题也曾在golang-nuts中得到Go 官方负责东谈主员的阐述(https://groups.google.com/g/golang-nuts/c/YZVFzwnPixM)， 并已向社区提交issue， 有待 Go 官方的进一步竖立(https://github.com/golang/go/issues/61730).

除了上述对使用Go原生逃遁分析算法的编译器生成的二进制的测试， 咱们还将DBI-Go用于评测一个在Gollvm (一个基于 LLVM 的 Go 编译器)上重构的Go逃遁分析算法. 通过用DBI-Go检测经重构逃遁分析算法后的Gollvm生成的二进制中是否有犯科的内存援用， 来判断重构后的新逃遁分析算法的正确性， 并扶持开采东谈主员进行 Debug. 在执行评测中， 用DBI-Go不错发现新逃遁分析算法引起的内存分派问题. 以代码5和代码6为例， 代码5中的 New函数将字面量prefixError{}的地址复返出函数; 代码6中， 对象b 的地址被全局对象gm获取， 凭证逃遁不变式2它们理当堆分派. DBI-Go发现重构后的逃遁分析算法在特定场景下会将代码5中本应在堆均分派的prefixError{}以及代码6中本应在堆均分派的b均分派在栈上. 通过这些例子， DBI-Go匡助新逃遁算法的开采者竖立了重构后的逃遁算法上的Bug.

代码5. DBI-Go发现的新逃遁算法出错的例子1.

1. package nomain

2. type prefixError struct{s string}

3. func New(f string， x ...interface{}) error {

4. 　// 误将字面量prefixError{}分派到栈上

5. 　return & prefixError{}

6. }

7. func (e *prefixError) Error() string {

8. 　　return “1” + e.s

9. }

代码6. DBI-Go发现的新逃遁算法出错的例子2.

1. var gm map[string]interface{}

2.

3. func Test() {

4.　 // 误将b分派到栈上

5. 　var b int

6. 　gm[“1”] = & b

7. }

4.2 额外支出 4.2.1 额外运行时支出

比较于只需在运行前履行一次的静态分析和驱动化， 插桩的回调函数带来的额外运行时支出在反复履行时会占据主要比例， 这些额外的运行时支出主要包括以下几部分: (1) 调用回调函数的支出; (2)获取Go的运行时信息的支出; (3)利勤劳令1和功令2进走时行时考据的支出. 为显然解这些额外运行时支出的影响， 咱们使用第4.1节中所述的Go 轨范库和编译器具链中的277个包中的测例进行了测试. 最终， 记载了插桩的回调函数带来的额外运行时支出比较于成功履行时所虚耗的支出的比值. 为了表述浅易， 不才文使用Rc/o 泄露额外的运行时支出比较于成功履行时所虚耗的支出的比值.

为显然解Rc/o的漫衍， 对得到的额外支出数据使用了KDE (kernel density estimation， 核密度测度， 一种用于测度随即变量的概率密度函数的非参数方法)[40， 41]测度了Rc/o在这277个包中的漫衍密度， 如后文图10所示. 该弧线的波峰在Rc/o约为0.25处达到， 且绝大多数的额外支出比较于原生支出的比值均小于2 (93.3%)惟一在少许数store密集型的关节中该比值才会大于4 (2.8%). 产生额外的2倍运行时支出是不错承受的.

图 10 Rc/o的核密度漫衍弧线 4.2.2 额外驱动化支出

在前文中提到， 由于驱动化部分只需在运行前履行一次， 因此其比较于不错反复履行的运行时支出不错忽略. 但用于驱动化的该部分支出在使用时也会对总时候酿成影响， 因此对该部分支出的测试亦然必要的. 额外的驱动化支出包括以下几部分时候: (1) Pin 加载用户二进制的支出; (2) 反汇编的支出; (3) 使用静态分析， 利用Go的写樊篱机制复原Go store语义的支出. 使用和第4.2.1节沟通的测试集和测试方式， 通过记载额外的驱动化支出与原生支出的比值， 并使用KDE测度漫衍密度， 不错得到图11. 为了表述浅易， 不才文使用Ri/o来泄露额外的驱动化支出比较于原生支出的比值.

图 11 Ri/o 的核密度漫衍弧线

图11有两波波峰， 第1波爽快在Ri/o为4处， 另一波对应的 Ri/o 则进步了 100. 比较于原生支出 100 倍的额外驱动化支出是惊东谈主的. 为显然解该部分比值为怎么此之高， 咱们将Ri/o大于 100 的部分单独进行分析. 通过分析发现， 这部分例子原生支出很小， 均不进步10 ms， 与其相对应的DBI-Go的驱动化支出均在500 ms 掌握， 如图12所示， 仅在极个别例子上驱动化支出进步了1500 ms. 这标明 DBI-Go的驱动化支出的下限在 500 ms掌握， 因此在遭逢原生支出很小， 惟一几毫秒的测例时显得Ri/o很大. 但执行上， 500 ms的驱动化支出是填塞不错接受的.

图 12 比值大于100的额外驱动化支出与原生支出 4.3 误报率测试

为了考据 DBI-Go所利用的Go写樊篱机制以考取 3.4 节中的两个方法对误报率的影响， 对这些方法进行了单独或组合的测试. 不才文中， 使用“方法 1” 来代表第3.4 节中的“过滤掉非Go 函数” 方法; 使用“方法 2” 来代表第3.4 节中的“过滤掉Go 运行时函数”方法; 使用“方法 3”来代表使用第3.4 节中的“过滤掉非指针 store” 方法; 使用“无”代表不使用任何方法， 成功插桩Go二进制中的通盘store. 咱们使用 Go 的轨范库和编译器具链提供的 277 个包， 测试方法与第 4.1 节沟通.

最终的测试遣散如表1所示. 从中看出， 单独使用方法1和2都莫得成果. 这是因为面前G 的二进制中都包含多数的运行时管理函数以及汇编函数等非Go函数， 单独过滤运行时函数或者非Go函数无法撤销在单一二进制(包)上的误报. 从表1中不错看出， 同期使用方法1和2比较单独的方法1或 2 不错大大镌汰误报的包的数目， 但此时误报率仍然较高， 这是因为此时还莫得复原Go二进制中store指针的语义， 仍对通盘Go 用户代码中的store进行查验. 单独使用方法3的误报率也较高， 原因在于Go运行时中有诸多违背Go逃遁不变式的store， 但运行时保证了其安全性. 同期使用方法2和方法3不错带来最低的误报率， 在测试的 277 个包中误报率为0. 在测试中， 方法1无法在方法3的基础上进一步镌汰误报， 这是因为Go编译器只会对 Go 函数插入写樊篱， 因此使用方法 3 就潜在的撤销了通盘非Go 函数带来的影响. 诚然方法1无法在方法 3的基础上进一步镌汰误报率， 但并不虞味着方法1是不消的. 方法1不错让方法3的静态分析阶段跳过诸多无道理的非Go函数， 镌汰驱动化阶段所带来额外支出， 因此方法 1 亦然必不可少的. 为了揭示方法1对减少驱动化支出的作用， 咱们只接纳方法2和方法3， 不接纳方法1去重迭第4.2.2节中的测试， 遣散炫夸在这277个包中， 总驱动化时候增多了约20.14%.

表 1 各个方法误报率测试遣散 4.4 开源技俩测试

为显然解信得过宇宙Go技俩中是否有违背Go逃遁不变式激发的内存安全问题， 咱们录取了18个在各个领域具有代表性的Go开源技俩来进行测试， 这些开源技俩触及Web、数据库、漫衍式系统、边际计较、云存储等多个领域. 录取的仓库如表2所示. 测试时使用和第4.1节相同的测试方法: 以包为单元， 将这些技俩提供的测试用例和Benchmark编译成可履行文献， 并随后使用DBI-Go 进行检测. 在这18个开源仓库中共有 1730个包提供了测试用例或者Benchmark. 临了的测试遣散炫夸， DBI-Go 在这些仓库中并未检测到问题.

表 2 测试的代表性 Go 开源技俩 4.5 适用性测试

上述测试中针对额外运行时支出、Go轨范库以及编译器具链的测试中所使用的Go编译器为现时的最新版块(Go1.20.5). 在对破绽笼罩率测试中， 咱们会凭证图1中每个issue所形容的Go版底本录取相应版块的 Go编译器. 最终遣散炫夸DBI-Go在这些Go版块中均可平常运行(Go1.11至Go1.20.5).

5 DBI-Go 的局限性盘考

详细来看， DBI-Go仍有进一步优化的优化空间. 对此， 本节列出来了面前DBI-Go的一些局限性及一些可能的处分念念路.

• 动态分析器具的代码笼罩率问题. DBI-Go是基于二进制插桩的动态检测器， 因此它无法检测Go关节中未被履行的旅途中的store提示. 这是通盘动态分析器具不得不濒临的问题. 为了改善这种情况， 不错使用基于代码笼罩率的暗昧测试等时刻来提高代码笼罩率.

• 现存功令可进一步推行. DBI-Go的运行时考据部分基于功令1和功令2. 其中功令2基于Go的逃遁不变式 2 “指向栈对象的指针人命期不可超出该栈对象”追思得到. 面前功令2所谈判的“人命期超出该栈对象”的情况分为5种: 全局对象、堆对象、更深的栈对象、栈帧更深的栈对象以过头他Goroutine栈对象. 但执行上“人命期超出该栈对象”还有其他情况， 比如更浅的作用域中的栈对象等. 由于这些情况在二进制中不好识别， 面前功令2未谈判. 因此功令2面前仍有进一步推行的空间.

• 误报无法填塞撤销. 面前基于gcWriteBarrier的store语义复原机制只适用于栈到堆或全局的store 提示. 违背逃遁不变式的栈到栈的store提示的检测面前仍需要插桩二进制中的通盘store提示. 尽管面前已作念了一些筛选， 比如不插桩运行时函数中的store， 跳过汇编函数等. 但由于忙活Go的高层语义信息， 比如类型形容符， 此时仍有可能带来误报. 同期， gcWriteBarrier是 Go 编译器在编译时间在源代码层级上增多的调用， 其以对象为粒度， 而非二进制中的提示. 若某对象中既包含指针类型也包含非指针类型(如uintptr)， 当该非指针类型的值等于某个栈指针时， 由于DBI-Go假设其为指针， 此时仍有可能产生误报. 若要根绝此类问题， 一种可能的方法是利用Go运行时中的bitmap. 该bitmap不错引导内存中那处是指针， 那处不是指针， Go的GC会利用该bitmap进行标记和清扫. 但引入bitmap会导致DBI-Go和Go的不同版块运行时强绑定， 镌汰其可扩展性， 同期还会进一步增大DBI-Go的额外支出. 因此， 详细谈判， 由于面前 DBI-Go 的误报率在可接受的范围中， 故莫得引入bitmap机制.

• ABI 需要凭证不同Go 版块进行适配. DBI-Gos达成的其核心纽一丝在于利用Go的ABI得到Goroutine 运行时栈信息. 面前 Go1.17 及以上版块接纳现行的ABI-Internal， 而 Go1.16.15 及以下则是另一套ABI. 为了保证适用性， 面前DBI-Go针对不同版块作念了适配. 若曩昔Go的ABI发生进一步变化， 则DBI-Go也需要进行相应的适配. 不外需要隆重的是， Go运行时中Goroutine的栈结构比较稳固， 其结构从2014年的Go1.4 到2023年最新的Go1.20版块均未发生变化. 这意味着曩昔只需对ABI进行适配， 而使用Goroutine栈信息的运行时考据部分则无需编削.

三级片在线播放

• 依赖Go的写樊篱机制的正确性. DBI-Go的分析面前依赖于Go编译器在编译时间插入的gcWriteBarrier函数， 若Go编译器由于误判等原因莫得对某store指针到堆的操作插入gcWriteBarrier函数， 则DBI-Go无法判断是否有违背逃遁不变式的情况.

• 需要二进制上的标记信息. DBI-Go需要二进制中的标记信息技艺平常劳动， 包括函数名、全局变量名等. 面前DBI-Go无法在填塞剥离标记信息的二进制上进行分析.

• 额外支出可进一步镌汰. 在额外支出方面， 面前回调函数的额外支出仍有连接优化的空间. Pin作为一个通用的动态二进制分析框架， 莫得针对Go的特定优化. DBI-Go在打算达成时本着快速原型化的理念， 也未针对Go作念多数优化. 面前 DBI-Go所作念的优化有使用基于匹配的方式跳过Go的运行时函数和一些非Go 函数(如一些汇编函数、C 函数)以及基于gcWriteBarrier机制只插桩可能store指针的提示. 曩昔基于Go 言语的特点不错探索更多的优化方式， 减少Pin插桩带来的额外支出.

• 无法自动竖立破绽. DBI-Go仅仅一个Go二进制中的破绽检测器， 它并不可自动竖立检测到的破绽. 破绽产生的原因有好多种， 比如逃遁分析的无理、编译优化的无理等. 通过DBI-Go检测出的破绽需要Go编译器开采东谈主员的进一步分析和竖立. 但DBI-Go的log不错匡助开采东谈主员更快的阐述破绽出现的位置及原因.

• 有待进一步大限制测试. 面前DBI-Go在信得过宇宙开源技俩上的测试尚未发现问题， 只在18个仓库上进行了测试， 笼罩面不及. 曩昔守望大概进行更大限制的测试， 以期找出开源仓库中的问题， 匡助改善Go言语软件的内存安全性， 提高其可靠性.

6 联系劳动 6.1 动态二进制分析

动态二进制分析框架， 如Pin[21]、Valgrind[42]、DynamoRIO[43]， 不错用于插桩肆意提示来履行为态分析. 这些器具为连接者们的分析带来了很大的便利. Amitabha等东谈主[44]连接了怎么有用地插桩x86机器码中的内存拜谒以相沿软件事务内存和分析. Patil等东谈主[45]基于 Pin打算了Pinplay， 一个基于履行拿获和详情味重放的并行关节分析框架. Zhong等东谈主[17]基于DynamoRIO打算了一个动态二进制器具， 用于检测Go中的并提问题.

基于动态二进制分析的破绽检测包括前边提到的并发破绽分析、罪戾分析[46]、逆向工程[47] 和履行重放[48]等.

6.2 内存破绽检测

面前已有的内存联系的破绽检测劳动东如果针对C/C++这种具有弱静态类型系统的编程言语来进行的， 因为强制类型蜕变、肆意指针的存在使得悬空援用、范围溢出等内存破绽更容易发生， Song等东谈主于2013年[30]通过系统性地建立内存损坏的一般模子， 揭示了C/C++容易遭受内存破绽的主要原因. 现存的内存破绽检测劳动依赖于静态关节分析或动态关节分析来进行.

静态检测: 分析关节(源) 代码， 并生成关于通盘可能的代码履行都是保守正确的遣散. 静态检测的一部单干作基于气象化考据: Clarke 等东谈主提议了一种使用有界模子查验(BMC)对ANSI-C关节进行气象化考据的器具[49]来检测内存问题. 更多的静态检测劳动则是基于标记履行: CUTE[50]通过衔尾标记履行和具体履行， 将内存图作为输入来履行自动化测试; EXE[51]是利用标记履行来自动生成导致执行代码崩溃的输入， 进行快速的无理定位; Klee[52]则是通过标记履行来自动生成测试.

动态检测: 通过分析单个关节的履行， 并输出仅对单个运行有用的精确分析遣散. 消毒器 (sanitizer)——静态插入运行时监视器， 并在运行时进行检测——是动态检测器具的典型代表. Serebryany等东谈主在2012年提议了AddressSanitizer (ASAN)[28]， 它通过插桩应用关节中的内存拜谒操作， 在运行时建模影子内存， 从而能识别缓冲区溢出、悬垂指针、内存泄漏等内存破绽. 由于它大概在不捐躯完备性的情况下达成了检测效率， AddressSanitizer也曾被集成到许多常用的编译器具链中， 包括针对C/C++的编译器GCC、LLVM， 以及 Go 言语编译器. 但ASAN面前在Go编译器中的使用场景受限， 仅能检测Go言语中庸C言语进行交互的联系代码上的内存无理[53]， 关于纯Go言语代码尚不相沿. ASAN与DBI-Go的沟通点在于二者都是基于插桩， ASAN是在编译时插桩， DBI-Go是基于动态二进制插桩. 区别在于ASAN的打算方针是检测诸如缓冲区溢出之类的通用的内存破绽， 不可检测Go中违背Go逃遁不变式的store; 且其所能检测的内存破绽惟一在被触发时技艺发现(如内存被开释、指针被解援用时)， 此时Go关节可能也曾崩溃. 而DBI-Go则是针对Go言语有益打算， 利用Go的逃遁不变式这一额外特点， 不错在内存隐患发生的第一现场就报错(比如将栈地址存入堆时). 因此即使ASAN不错相沿纯Go的代码， 其也无法代替DBI-Go. 雷同地， 还有许多使用雷同方式进行针对其他问题检测的破绽检测器具， 如用于检测未驱动化内存的使用情况的 MemorySanitizer[54]， 用于检测数据竞争的ThreadSanitizer[55]， 利用动态内存查验来检测对象有用性的EffectiveSan[56] 等. Song等东谈主[29] 则是在2019 年对Sanitizing这种时刻进行了对比追思， 形容了不同的Sanitizer器具的性能和可扩展性. 此外， 还有部单干作通过修改运行时系统来达成运行时检测， 如DieHard[57]、SoftBound[58].

6.3 Go 的破绽检测

面前针对Go的破绽检测已有许多劳动. Lange等东谈主[19]为Go中的音问传递机制进行建模， 为Go的音问传递机制提议了一个考据框架. Lauinger等东谈主[33]提议了go-safer， 一种全新的静态分析器具， 用来识别Go源代码中对unsafe包的不安全使用. Wang等东谈主[59]打算了HERO， 用于检测Go中依赖管理导致的问题. Liu等东谈主[18]提议了GCatch， 用于自动检测和竖立Go中的并提问题. Chabbi等东谈主[31] 使用现存的数据竞争检测器在 Uber技俩中发现了进步2000个数据竞争. Li等东谈主[60]打算了 CryptoGo， 用于检测Go中庸加解密联系API的误用. Zhong等东谈主[17] 初度提议了使用动态二进制插桩的方式检测Go中的并提问题. 面前与Go破绽检测联系的劳动多数网络在对用户代码的破绽的检测， 且多与并发联系. 本文提议的DBI-Go是首个考据Go编译器生成的代码的是否安闲Go逃遁不变式的器具.

6.4 Go 的逃遁分析

面前Go中庸逃遁分析的联系劳动较少. Google曾在2015年追思了其时Go逃遁分析的劣势， 指出了其分析的保守之处[61]. Wang等东谈主[20]则隆重到了Go逃遁分析的一些保守之处， 其劳动使得一些对象不错绕过 Go的逃遁分析， 从而简约堆内存的使用.

7 追思与估量

本文主要提议了DBI-Go， 一个用于Go应用关节的新式破绽检测器具. DBI-Go使用静态分析扶持动态二进制插桩的分析方法， 以Go二进制文献为输入， 检测Go编译器生成的代码中是否有违背Go逃遁不变式的store. DBI-Go使用静态分析的方法， 衔尾Go的gcWriteBarrier机制复原Go的store语义. DBI-Go的运行时回调函数在运行时衔尾Go的ABI商定得到Go的运行时栈信息来扶持分析. DBI-Go使用约1000行C++代码达成， 为比较轻量的检测器具.

实验标明， DBI-Go不错检测出面前Go社区也曾阐述的问题， 呈现了较高的破绽笼罩率， 同期 DBI-Go还得胜检测出一个之前未知的问题， 面前该问题也曾得到Go官方的阐述并在恭候进一步竖立. 在执行技俩上的应用还标明 DBI-Go不错扶持开采东谈主员对内存优化联系算法， 如逃遁分析算法， 进行优化和重构， 考据算法的正确性. 对误报率的测试则标明DBI-Go所选用的方法不错有用地镌汰误报. 实验遣散还标明， DBI-Go在不同版块的Go编译器编译出的二进制上都能平常劳动(Go1.11至 Go1.20.5)， 体现了较高的可扩展性. 额外支出的测试遣散则标明DBI-Go会产生在可接受范围内的约常数倍的支出.

本文还分析了DBI-Go的不及之处. 曩昔将连接改造DBI-Go， 以期达成更高的代码笼罩率、更高的精度以及更小的额外支出， 并将进行更大限制， 更大范围的测试鑫系列第二季， 以期找到更多破绽， 匡助改善Go言语软件的可靠性和安全性.