共计 5551 个字符，预计需要花费 14 分钟才能阅读完成。
摘要： 近几年，Rust 语言以极快的增长速度取得了大量关注。其特点是在保障高安全性的同时，取得不输 C /C++ 的性能。在 Rust 被很多我的项目应用当前，其理论安全性体现到底如何呢？
近几年，Rust 语言以极快的增长速度取得了大量关注。其特点是在保障高安全性的同时，取得不输 C /C++ 的性能，让零碎编程畛域难得的呈现了充满希望的新抉择。在 Rust 被很多我的项目应用当前，其理论安全性体现到底如何呢？往年 6 月份，来自 3 所大学的 5 位学者在 ACM SIGPLAN 国内会议（PLDI’20）上发表了一篇研究成果，针对近几年应用 Rust 语言的开源我的项目中的平安缺点进行了全面的考察。
这项钻研考察了 5 个应用 Rust 语言开发的软件系统，5 个被宽泛应用的 Rust 库，以及两个破绽数据库。考察总共波及了 850 处 unsafe 代码应用、70 个内存平安缺点、100 个线程平安缺点。
在考察中，研究员不光查看了所有破绽数据库中报告的缺点和软件公开报告的缺点，还查看了所有开源软件代码仓库中的提交记录。通过人工的剖析，他们界定出提交所修复的 BUG 类型，并将其归类到相应的内存平安 / 线程平安问题中。所有被考察过的问题都被整顿到了公开的 Git 仓库中：https://github.com/system-pclub/rust-study
内存平安问题的剖析
这项钻研考察了 70 个内存平安问题。针对于每个问题，研究者认真的剖析了问题呈现的根因（cause）和问题导致的成果（effect）。问题根因是通过批改问题时提交的 patch 代码来界定的——即编码的谬误产生在哪儿；问题的成果是指代码运行造成可察看的谬误的地位，比方呈现缓冲区溢出的代码地位。因为从根因到成果有个传递过程，这两者有时候是相隔很远的。依据根因和成果所在的代码区域不同，研究者将谬误分为了 4 类：safe -> safe、safe -> unsafe、unsafe -> safe、unsafe -> unsafe。比方：如果编码谬误呈现在 safe 代码中，但造成的成果体现在 unsafe 代码中，那么就归类为 safe -> unsafe。
另一方面，依照传统的内存问题分类，问题又能够分为空间内存平安（Wrong Access）和工夫内存平安（Lifetime Violation）两大类，进一步可细分为缓冲区溢出（Buffer overflow）、解援用空指针（Null pointer dereferencing）、拜访未初始化内存（Reading uninitialized memory）、谬误开释（Invalid free）、开释后应用（Use after free）、反复开释（Double free）等几个小类。依据这两种分类维度，问题的统计数据如下：
从统计后果中能够看出，齐全不波及 unsafe 代码的内存平安问题只有一个。进一步考察发现这个问题呈现在 Rust 晚期的 v0.3 版本中，之后的稳固版本编译器曾经能拦挡这个问题。因而能够说：Rust 语言的 safe 代码机制能十分无效的防止内存平安问题，所有稳固版本中发现的内存平安问题都和 unsafe 代码无关。
然而，这并不意味着咱们只有查看所有 unsafe 代码段就能无效发现问题。因为有时候问题根因会呈现在 safe 代码中，只是成果产生在 unsafe 代码段。论文中举了一个例子：（hi3ms 没有 Rust 代码编辑性能，只能拿其余语言对付下了）
Css 代码
pub fn sign(data: Option<&[u8]>) {
let p = match data {Some(data) => BioSlice::new(data).as_ptr(),
None => ptr::null_mut(),};
unsafe {let cms = cvt_p(CMS_sign(p));
}
}在这段代码中，p 是 raw pointer 类型，在 safe 代码中，当 data 含有值（Some 分支）时，分支里试图创立一个 BioSlice 对象，并将对象指针赋给 p。然而，依据 Rust 的生命周期规定，新创建的 BioSlice 对象在 match 表达式完结时就被开释了，p 在传给 CMS_sign 函数时是一个野指针。 这个例子中的 unsafe 代码段没有任何问题，如果只检视 unsafe 代码，不可能发现这个开释后应用的谬误。 对此问题批改后的代码如下：
Css 代码
pub fn sign(data: Option<&[u8]>) {
let bio = match data {Some(data) => Some(BioSlice::new(data)),
None => None,
};
let p = bio.map_or(ptr::null_mut(),|p| p.as_ptr());
unsafe {let cms = cvt_p(CMS_sign(p));
}
}批改后的代码正确的缩短了 bio 的生命周期。所有的批改都只产生在 safe 代码段，没有改变 unsafe 代码。
既然问题都会波及 unsafe 代码，那么把 unsafe 代码打消掉是否能够防止问题？研究者进一步的考察了所有 BUG 批改的策略，发现大部分的批改波及了 unsafe 代码，然而只有很少的一部分批改齐全移除了 unsafe 代码。这阐明 unsafe 代码是不可能完全避免的。
unsafe 的价值是什么？为什么不可能齐全去除？研究者对 600 处 unsafe 的应用目标进行了考察，发现其中 42% 是为了复用已有代码（比方从现有 C 代码转换成的 Rust 代码，或者调用 C 库函数），22% 是为了改良性能，剩下的 14% 是为了实现性能而绕过 Rust 编译器的各种校验。
进一步的钻研表明， 应用 unsafe 的办法来拜访偏移的内存（如 slice::get_unchecked()），和应用 safe 的下标形式拜访相比，unsafe 的速度能够快 4~5 倍。 这是因为 Rust 对缓冲区越界的运行时校验所带来的，因而在某些性能要害区域，unsafe 的作用不可短少。
须要留神的是，unsafe 代码段并不见得蕴含 unsafe 的操作。研究者发现有 5 处 unsafe 代码，即便去掉 unsafe 标签也不会有任何编译谬误——也就是说，从编译器角度它齐全能够作为 safe 代码。将其标为 unsafe 代码是为了给使用者提醒要害的调用契约，这些契约不可能被编译器查看。一个典型的例子是 Rust 规范库中的 String::from_utf8_unchecked() 函数，这个函数外部并没有任何 unsafe 操作，然而却被标为了 unsafe。其起因是这个函数间接从用户提供的一片内存来结构 String 对象，但并没有对内容是否为非法的 UTF- 8 编码进行查看，而 Rust 要求所有的 String 对象都必须是非法的 UTF- 8 编码字符串。也就是说，String::from_utf8_unchecked() 函数的 unsafe 标签只是用来传递逻辑上的调用契约，这种契约和内存平安没有间接关系，然而如果违反契约，却可能导致其余中央（有可能是 safe 代码）的内存平安问题。这种 unsafe 标签是不能去除的。
即便如此，在可能的状况下，打消 unsafe 代码段的确是个无效的平安改良办法。研究者考察了 130 个去掉 unsafe 的批改记录，发现其中 43 个通过代码的重构把 unsafe 代码段彻底改为了 safe 代码，剩下的 87 个则通过将 unsafe 代码封装出 safe 的接口来保障了安全性。
线程平安问题的剖析
这项钻研考察了 100 个线程平安问题。问题被分为了两类：阻塞式问题（造成死锁）和非阻塞式问题（造成数据竞争），其中阻塞式问题有 59 个，之中 55 个都和同步原语（Mutex 和 Condvar）无关：
尽管 Rust 号称能够进行“无畏并发”的编程，并且提供了精心设计的同步原语以防止并发问题。然而，仅仅用 safe 代码就可能导致反复加锁造成的死锁，更蹩脚的是， 有些问题甚至是 Rust 的特有设计所带来的，在其余语言中反而不会呈现。 论文中给出了一个例子：
Css 代码
fn do_request() {
//client: Arc<RwLock<Inner>>
match connect(client.read().unwrap().m) {Ok(_) => {let mut inner = client.write().unwrap();
inner.m = mbrs;
}
Err(_) => {}};
}这段代码中，client 变量被一个读写锁（RwLock）爱护。RwLock 的办法 read() 和 write() 会主动对变量加锁，并返回 LockResult 对象，在 LockResult 对象生命周期完结时，主动解锁。
显然，该段代码的作者认为 client.read() 返回的长期 LockResult 对象在 match 外部的匹配分支之前就被开释并解锁了，因而在 match 分支中能够再次用 client.write() 对其加锁。然而，Rust 语言的生命周期规定使得 client.read() 返回的对象的理论生命周期被缩短到了 match 语句完结，所以该段代码理论后果是在 read() 的锁还没有开释时又尝试获取 write() 锁，导致死锁。
这种长期对象生命周期规定在 Rust 语言中是一个十分艰涩的规定，对其的具体解释能够参见这篇文章。
依据生命周期的正确用法，该段代码起初被批改成了这样：
Css 代码
fn do_request() {
//client: Arc<RwLock<Inner>>
let result = connect(client.read().unwrap().m);
match result {Ok(_) => {let mut inner = client.write().unwrap();
inner.m = mbrs;
}
Err(_) => {}};
}批改当前，client.read() 返回的长期对象在该行语句完结后即被开释，不会始终加锁到 match 语句外部。
对于 41 个非阻塞式问题，其中 38 个都是因为对共享资源的爱护不当而导致的。依据对共享资源的不同爱护办法，以及代码是否为 safe，这些问题进一步被分类如下：
38 个问题中，有 23 个产生在 unsafe 代码，15 个产生在 safe 代码。只管 Rust 设置了严格的数据借用和拜访规定，但因为并发编程依赖于程序的逻辑和语义，即便是 safe 代码也不可能完全避免数据竞争问题。论文中给出了一个例子：
Css 代码
impl Engine for AuthorityRound {fn generate_seal(&self) -> Seal {if self.proposed.load() {return Seal::None;}
self.proposed.store(true);
return Seal::Regular(...);
}
}这段代码中，AuthorityRound 构造的 proposed 成员是一个 boolean 类型的原子变量，load() 会读取变量的值，store() 会设置变量的值。显然，这段代码心愿在并发操作时，只返回一次 Seal::Regular(…)，之后都返回 Seal::None。然而，这里对原子变量的操作方法没有正确的解决。如果有两个线程同时执行到 if 语句，并同时读取到 false 后果，该办法可能给两个线程都返回 Seal::Regular(…)。
对该问题进行批改后的代码如下，这里应用了 compare_and_swap() 办法，保障了对原子变量的读和写在一个不可抢占的原子操作中一起实现。
Css 代码
impl Engine for AuthorityRound {fn generate_seal(&self) -> Seal {if !self.proposed.compare_and_swap(false, true) {return Seal::Regular(...);
}
return Seal::None;
}
}这种数据竞争问题没有波及任何 unsafe 代码，所有操作都在 safe 代码中实现。 这也阐明了即便 Rust 语言设置了严格的并发查看规定，程序员依然要在编码中人工保障并发拜访的正确性
对 Rust 缺点查看工具的倡议
显然，从后面的考察可知，光凭 Rust 编译器自身的查看并不足以防止所有的问题，甚至某些艰涩的生命周期还可能触发新的问题。研究者们倡议对 Rust 语言减少以下的查看工具：
1. 改良 IDE。当程序员选中某个变量时，主动显示其生命周期范畴，尤其是对于 lock() 办法返回的对象的生命周期。这能够无效的解决因为对生命周期了解不当而产生的编码问题。
2. 对内存平安进行动态查看。研究者们实现了一个动态扫描工具，对于开释后应用的内存平安问题进行查看。在对参加钻研的 Rust 我的项目进行扫描后，工具新发现了 4 个之前没有被发现的内存平安问题。阐明这种动态查看工具是有必要的。
3. 对反复加锁问题进行动态查看。研究者们实现了一个动态扫描工具，通过剖析 lock() 办法返回的变量生命周期内是否再次加锁，来检测反复加锁问题。在对参加钻研的 Rust 我的项目进行扫描后，工具新发现了 6 个之前没有被发现的死锁问题。
论文还对动静检测、fuzzing 测试等办法的利用提出了倡议。
论断
1. Rust 语言的 safe 代码对于空间和工夫内存平安问题的查看十分无效，所有稳固版本中呈现的内存平安问题都和 unsafe 代码无关。
2. 尽管内存平安问题都和 unsafe 代码无关，但大量的问题同时也和 safe 代码无关。有些问题甚至源于 safe 代码的编码谬误，而不是 unsafe 代码。
3. 线程平安问题，无论阻塞还是非阻塞，都能够在 safe 代码中产生，即便代码完全符合 Rust 语言的规定。
4. 大量问题的产生是因为编码人员没有正确理解 Rust 语言的生命周期规定导致的。
5. 有必要针对 Rust 语言中的典型问题，建设新的缺点检测工具。
点击关注，第一工夫理解华为云陈腐技术~