近幾年，Rust語(yǔ)言以極快的增長(zhǎng)速度獲得了大量關(guān)注。其特點(diǎn)是在保證高安全性的同時(shí)，獲得不輸C/C++的性能，讓系統(tǒng)編程領(lǐng)域難得的出現(xiàn)了充滿希望的新選擇。在Rust被很多項(xiàng)目使用以后，其實(shí)際安全性表現(xiàn)到底如何呢？

今年6月份，來(lái)自3所大學(xué)的5位學(xué)者在ACM SIGPLAN國(guó)際會(huì)議（PLDI'20）上發(fā)表了一篇研究成果，針對(duì)近幾年使用Rust語(yǔ)言的開(kāi)源項(xiàng)目中的安全缺陷進(jìn)行了全面的調(diào)查。這項(xiàng)研究調(diào)查了5個(gè)使用Rust語(yǔ)言開(kāi)發(fā)的軟件系統(tǒng)，5個(gè)被廣泛使用的Rust庫(kù)，以及兩個(gè)漏洞數(shù)據(jù)庫(kù)。調(diào)查總共涉及了850處unsafe代碼使用、70個(gè)內(nèi)存安全缺陷、100個(gè)線程安全缺陷。

在調(diào)查中，研究員不光查看了所有漏洞數(shù)據(jù)庫(kù)中報(bào)告的缺陷和軟件公開(kāi)報(bào)告的缺陷，還查看了所有開(kāi)源軟件代碼倉(cāng)庫(kù)中的提交記錄。通過(guò)人工的分析，他們界定出提交所修復(fù)的BUG類(lèi)型，并將其歸類(lèi)到相應(yīng)的內(nèi)存安全/線程安全問(wèn)題中。

內(nèi)存安全問(wèn)題的分析

這項(xiàng)研究調(diào)查了70個(gè)內(nèi)存安全問(wèn)題。針對(duì)于每個(gè)問(wèn)題，研究者仔細(xì)的分析了問(wèn)題出現(xiàn)的根因（cause）和問(wèn)題導(dǎo)致的效果（effect）。問(wèn)題根因是通過(guò)修改問(wèn)題時(shí)提交的patch代碼來(lái)界定的——即編碼的錯(cuò)誤發(fā)生在哪兒；問(wèn)題的效果是指代碼運(yùn)行造成可觀察的錯(cuò)誤的位置，比如出現(xiàn)緩沖區(qū)溢出的代碼位置。由于從根因到效果有個(gè)傳遞過(guò)程，這兩者有時(shí)候是相隔很遠(yuǎn)的。根據(jù)根因和效果所在的代碼區(qū)域不同，研究者將錯(cuò)誤分為了4類(lèi)：safe -> safe、safe -> unsafe、unsafe -> safe、unsafe -> unsafe。比如：如果編碼錯(cuò)誤出現(xiàn)在safe代碼中，但造成的效果體現(xiàn)在unsafe代碼中，那么就歸類(lèi)為safe -> unsafe。

另一方面，按照傳統(tǒng)的內(nèi)存問(wèn)題分類(lèi)，問(wèn)題又可以分為空間內(nèi)存安全（Wrong Access）和時(shí)間內(nèi)存安全（Lifetime Violation）兩大類(lèi)，進(jìn)一步可細(xì)分為緩沖區(qū)溢出（Buffer overflow）、解引用空指針（Null pointer dereferencing）、訪問(wèn)未初始化內(nèi)存（Reading uninitialized memory）、錯(cuò)誤釋放（Invalid free）、釋放后使用（Use after free）、重復(fù)釋放（Double free）等幾個(gè)小類(lèi)。根據(jù)這兩種分類(lèi)維度，問(wèn)題的統(tǒng)計(jì)數(shù)據(jù)如下：

從統(tǒng)計(jì)結(jié)果中可以看出，完全不涉及unsafe代碼的內(nèi)存安全問(wèn)題只有一個(gè)。進(jìn)一步調(diào)查發(fā)現(xiàn)這個(gè)問(wèn)題出現(xiàn)在Rust早期的v0.3版本中，之后的穩(wěn)定版本編譯器已經(jīng)能攔截這個(gè)問(wèn)題。因此可以說(shuō)：Rust語(yǔ)言的safe代碼機(jī)制能非常有效的避免內(nèi)存安全問(wèn)題，所有穩(wěn)定版本中發(fā)現(xiàn)的內(nèi)存安全問(wèn)題都和unsafe代碼有關(guān)。

然而，這并不意味著我們只要檢查所有unsafe代碼段就能有效發(fā)現(xiàn)問(wèn)題。因?yàn)橛袝r(shí)候問(wèn)題根因會(huì)出現(xiàn)在safe代碼中，只是效果產(chǎn)生在unsafe代碼段。論文中舉了一個(gè)例子：（hi3ms沒(méi)有Rust代碼編輯功能，只能拿其他語(yǔ)言湊合下了）

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類(lèi)型，在safe代碼中，當(dāng)data含有值（Some分支）時(shí)，分支里試圖創(chuàng)建一個(gè)BioSlice對(duì)象，并將對(duì)象指針賦給p。然而，根據(jù)Rust的生命周期規(guī)則，新創(chuàng)建的BioSlice對(duì)象在match表達(dá)式結(jié)束時(shí)就被釋放了，p在傳給CMS_sign函數(shù)時(shí)是一個(gè)野指針。這個(gè)例子中的unsafe代碼段沒(méi)有任何問(wèn)題，如果只檢視unsafe代碼，不可能發(fā)現(xiàn)這個(gè)釋放后使用的錯(cuò)誤。對(duì)此問(wèn)題修改后的代碼如下：

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)); } }

修改后的代碼正確的延長(zhǎng)了bio的生命周期。所有的修改都只發(fā)生在safe代碼段，沒(méi)有改動(dòng)unsafe代碼。 既然問(wèn)題都會(huì)涉及unsafe代碼，那么把unsafe代碼消除掉是否可以避免問(wèn)題？研究者進(jìn)一步的調(diào)查了所有BUG修改的策略，發(fā)現(xiàn)大部分的修改涉及了unsafe代碼，但是只有很少的一部分修改完全移除了unsafe代碼。這說(shuō)明unsafe代碼是不可能完全避免的。

unsafe的價(jià)值是什么？為什么不可能完全去除？研究者對(duì)600處unsafe的使用目的進(jìn)行了調(diào)查，發(fā)現(xiàn)其中42%是為了復(fù)用已有代碼（比如從現(xiàn)有C代碼轉(zhuǎn)換成的Rust代碼，或者調(diào)用C庫(kù)函數(shù)），22%是為了改進(jìn)性能，剩下的14%是為了實(shí)現(xiàn)功能而繞過(guò)Rust編譯器的各種校驗(yàn)。

進(jìn)一步的研究表明，使用unsafe的方法來(lái)訪問(wèn)偏移的內(nèi)存（如slice::get_unchecked()），和使用safe的下標(biāo)方式訪問(wèn)相比，unsafe的速度可以快4~5倍。這是因?yàn)镽ust對(duì)緩沖區(qū)越界的運(yùn)行時(shí)校驗(yàn)所帶來(lái)的，因此在某些性能關(guān)鍵區(qū)域，unsafe的作用不可缺少。

需要注意的是，unsafe代碼段并不見(jiàn)得包含unsafe的操作。研究者發(fā)現(xiàn)有5處unsafe代碼，即使去掉unsafe標(biāo)簽也不會(huì)有任何編譯錯(cuò)誤——也就是說(shuō)，從編譯器角度它完全可以作為safe代碼。將其標(biāo)為unsafe代碼是為了給使用者提示關(guān)鍵的調(diào)用契約，這些契約不可能被編譯器檢查。一個(gè)典型的例子是Rust標(biāo)準(zhǔn)庫(kù)中的String::from_utf8_unchecked()函數(shù)，這個(gè)函數(shù)內(nèi)部并沒(méi)有任何unsafe操作，但是卻被標(biāo)為了unsafe。其原因是這個(gè)函數(shù)直接從用戶(hù)提供的一片內(nèi)存來(lái)構(gòu)造String對(duì)象，但并沒(méi)有對(duì)內(nèi)容是否為合法的UTF-8編碼進(jìn)行檢查，而Rust要求所有的String對(duì)象都必須是合法的UTF-8編碼字符串。

也就是說(shuō)，String::from_utf8_unchecked()函數(shù)的unsafe標(biāo)簽只是用來(lái)傳遞邏輯上的調(diào)用契約，這種契約和內(nèi)存安全沒(méi)有直接關(guān)系，但是如果違反契約，卻可能導(dǎo)致其他地方（有可能是safe代碼）的內(nèi)存安全問(wèn)題。這種unsafe標(biāo)簽是不能去除的。

即便如此，在可能的情況下，消除unsafe代碼段確實(shí)是個(gè)有效的安全改進(jìn)方法。研究者調(diào)查了130個(gè)去掉unsafe的修改記錄，發(fā)現(xiàn)其中43個(gè)通過(guò)代碼的重構(gòu)把unsafe代碼段徹底改為了safe代碼，剩下的87個(gè)則通過(guò)將unsafe代碼封裝出safe的接口來(lái)保證了安全性。

線程安全問(wèn)題的分析

這項(xiàng)研究調(diào)查了100個(gè)線程安全問(wèn)題。問(wèn)題被分為了兩類(lèi)：阻塞式問(wèn)題（造成死鎖）和非阻塞式問(wèn)題（造成數(shù)據(jù)競(jìng)爭(zhēng)），其中阻塞式問(wèn)題有59個(gè)，之中55個(gè)都和同步原語(yǔ)（Mutex和Condvar）有關(guān)：

雖然Rust號(hào)稱(chēng)可以進(jìn)行“無(wú)畏并發(fā)”的編程，并且提供了精心設(shè)計(jì)的同步原語(yǔ)以避免并發(fā)問(wèn)題。然而，僅僅用safe代碼就可能導(dǎo)致重復(fù)加鎖造成的死鎖，更糟糕的是，有些問(wèn)題甚至是Rust的特有設(shè)計(jì)所帶來(lái)的，在其他語(yǔ)言中反而不會(huì)出現(xiàn)。論文中給出了一個(gè)例子：

Css代碼

fn do_request() { //client: Arc> match connect(client.read().unwrap().m) { Ok(_) => { let mut inner = client.write().unwrap(); inner.m = mbrs; } Err(_) => {} }; }

這段代碼中，client變量被一個(gè)讀寫(xiě)鎖（RwLock）保護(hù)。RwLock的方法read()和write()會(huì)自動(dòng)對(duì)變量加鎖，并返回LockResult對(duì)象，在LockResult對(duì)象生命周期結(jié)束時(shí)，自動(dòng)解鎖。

顯然，該段代碼的作者以為client.read()返回的臨時(shí)LockResult對(duì)象在match內(nèi)部的匹配分支之前就被釋放并解鎖了，因此在match分支中可以再次用client.write()對(duì)其加鎖。但是，Rust語(yǔ)言的生命周期規(guī)則使得client.read()返回的對(duì)象的實(shí)際生命周期被延長(zhǎng)到了match語(yǔ)句結(jié)束，所以該段代碼實(shí)際結(jié)果是在read()的鎖還沒(méi)有釋放時(shí)又嘗試獲取write()鎖，導(dǎo)致死鎖。

根據(jù)生命周期的正確用法，該段代碼后來(lái)被修改成了這樣：

Css代碼

fn do_request() { //client: Arc> let result = connect(client.read().unwrap().m); match result { Ok(_) => { let mut inner = client.write().unwrap(); inner.m = mbrs; } Err(_) => {} }; }

修改以后，client.read()返回的臨時(shí)對(duì)象在該行語(yǔ)句結(jié)束后即被釋放，不會(huì)一直加鎖到match語(yǔ)句內(nèi)部。

對(duì)于41個(gè)非阻塞式問(wèn)題，其中38個(gè)都是因?yàn)閷?duì)共享資源的保護(hù)不當(dāng)而導(dǎo)致的。根據(jù)對(duì)共享資源的不同保護(hù)方法，以及代碼是否為safe，這些問(wèn)題進(jìn)一步被分類(lèi)如下：

38個(gè)問(wèn)題中，有23個(gè)發(fā)生在unsafe代碼，15個(gè)發(fā)生在safe代碼。盡管Rust設(shè)置了嚴(yán)格的數(shù)據(jù)借用和訪問(wèn)規(guī)則，但由于并發(fā)編程依賴(lài)于程序的邏輯和語(yǔ)義，即使是safe代碼也不可能完全避免數(shù)據(jù)競(jìng)爭(zhēng)問(wèn)題。論文中給出了一個(gè)例子：

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結(jié)構(gòu)的proposed成員是一個(gè)boolean類(lèi)型的原子變量，load()會(huì)讀取變量的值，store()會(huì)設(shè)置變量的值。顯然，這段代碼希望在并發(fā)操作時(shí)，只返回一次Seal::Regular(...)，之后都返回Seal::None。但是，這里對(duì)原子變量的操作方法沒(méi)有正確的處理。如果有兩個(gè)線程同時(shí)執(zhí)行到if語(yǔ)句，并同時(shí)讀取到false結(jié)果，該方法可能給兩個(gè)線程都返回Seal::Regular(...)。 對(duì)該問(wèn)題進(jìn)行修改后的代碼如下，這里使用了compare_and_swap()方法，保證了對(duì)原子變量的讀和寫(xiě)在一個(gè)不可搶占的原子操作中一起完成。

Css代碼

impl Engine for AuthorityRound { fn generate_seal(&self) -> Seal { if !self.proposed.compare_and_swap(false, true) { return Seal::Regular(...); } return Seal::None; } }

這種數(shù)據(jù)競(jìng)爭(zhēng)問(wèn)題沒(méi)有涉及任何unsafe代碼，所有操作都在safe代碼中完成。這也說(shuō)明了即使Rust語(yǔ)言設(shè)置了嚴(yán)格的并發(fā)檢查規(guī)則，程序員仍然要在編碼中人工保證并發(fā)訪問(wèn)的正確性。

對(duì)Rust缺陷檢查工具的建議

顯然，從前面的調(diào)查可知，光憑Rust編譯器本身的檢查并不足以避免所有的問(wèn)題，甚至某些晦澀的生命周期還可能觸發(fā)新的問(wèn)題。研究者們建議對(duì)Rust語(yǔ)言增加以下的檢查工具：

1. 改進(jìn)IDE。當(dāng)程序員選中某個(gè)變量時(shí)，自動(dòng)顯示其生命周期范圍，尤其是對(duì)于lock()方法返回的對(duì)象的生命周期。這可以有效的解決因?yàn)閷?duì)生命周期理解不當(dāng)而產(chǎn)生的編碼問(wèn)題。

2. 對(duì)內(nèi)存安全進(jìn)行靜態(tài)檢查。研究者們實(shí)現(xiàn)了一個(gè)靜態(tài)掃描工具，對(duì)于釋放后使用的內(nèi)存安全問(wèn)題進(jìn)行檢查。在對(duì)參與研究的Rust項(xiàng)目進(jìn)行掃描后，工具新發(fā)現(xiàn)了4個(gè)之前沒(méi)有被發(fā)現(xiàn)的內(nèi)存安全問(wèn)題。說(shuō)明這種靜態(tài)檢查工具是有必要的。

3. 對(duì)重復(fù)加鎖問(wèn)題進(jìn)行靜態(tài)檢查。研究者們實(shí)現(xiàn)了一個(gè)靜態(tài)掃描工具，通過(guò)分析lock()方法返回的變量生命周期內(nèi)是否再次加鎖，來(lái)檢測(cè)重復(fù)加鎖問(wèn)題。在對(duì)參與研究的Rust項(xiàng)目進(jìn)行掃描后，工具新發(fā)現(xiàn)了6個(gè)之前沒(méi)有被發(fā)現(xiàn)的死鎖問(wèn)題。

論文還對(duì)動(dòng)態(tài)檢測(cè)、fuzzing測(cè)試等方法的應(yīng)用提出了建議。

結(jié)論

1. Rust語(yǔ)言的safe代碼對(duì)于空間和時(shí)間內(nèi)存安全問(wèn)題的檢查非常有效，所有穩(wěn)定版本中出現(xiàn)的內(nèi)存安全問(wèn)題都和unsafe代碼有關(guān)。 2. 雖然內(nèi)存安全問(wèn)題都和unsafe代碼有關(guān)，但大量的問(wèn)題同時(shí)也和safe代碼有關(guān)。有些問(wèn)題甚至源于safe代碼的編碼錯(cuò)誤，而不是unsafe代碼。 3. 線程安全問(wèn)題，無(wú)論阻塞還是非阻塞，都可以在safe代碼中發(fā)生，即使代碼完全符合Rust語(yǔ)言的規(guī)則。 4. 大量問(wèn)題的產(chǎn)生是由于編碼人員沒(méi)有正確理解Rust語(yǔ)言的生命周期規(guī)則導(dǎo)致的。 5. 有必要針對(duì)Rust語(yǔ)言中的典型問(wèn)題，建立新的缺陷檢測(cè)工具。