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

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

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

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

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

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

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

然而，這并不意味著我們只要檢查所有unsafe代碼段就能有效發(fā)現(xiàn)問題。因?yàn)橛袝r(shí)候問題根因會(huì)出現(xiàn)在safe代碼中，只是效果產(chǎn)生在unsafe代碼段。論文中舉了一個(gè)例子：（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代碼中，當(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代碼段沒有任何問題，如果只檢視unsafe代碼，不可能發(fā)現(xiàn)這個(gè)釋放后使用的錯(cuò)誤。對(duì)此問題修改后的代碼如下：

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的生命周期。所有的修改都只發(fā)生在safe代碼段，沒有改動(dòng)unsafe代碼。 既然問題都會(huì)涉及unsafe代碼，那么把unsafe代碼消除掉是否可以避免問題？研究者進(jìn)一步的調(diào)查了所有BUG修改的策略，發(fā)現(xiàn)大部分的修改涉及了unsafe代碼，但是只有很少的一部分修改完全移除了unsafe代碼。這說明unsafe代碼是不可能完全避免的。

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

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

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

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

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

線程安全問題的分析

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

雖然Rust號(hào)稱可以進(jìn)行“無畏并發(fā)”的編程，并且提供了精心設(shè)計(jì)的同步原語以避免并發(fā)問題。然而，僅僅用safe代碼就可能導(dǎo)致重復(fù)加鎖造成的死鎖，更糟糕的是，有些問題甚至是Rust的特有設(shè)計(jì)所帶來的，在其他語言中反而不會(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è)讀寫鎖（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語言的生命周期規(guī)則使得client.read()返回的對(duì)象的實(shí)際生命周期被延長到了match語句結(jié)束，所以該段代碼實(shí)際結(jié)果是在read()的鎖還沒有釋放時(shí)又嘗試獲取write()鎖，導(dǎo)致死鎖。

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

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ì)象在該行語句結(jié)束后即被釋放，不會(huì)一直加鎖到match語句內(nèi)部。

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

38個(gè)問題中，有23個(gè)發(fā)生在unsafe代碼，15個(gè)發(fā)生在safe代碼。盡管Rust設(shè)置了嚴(yán)格的數(shù)據(jù)借用和訪問規(guī)則，但由于并發(fā)編程依賴于程序的邏輯和語義，即使是safe代碼也不可能完全避免數(shù)據(jù)競爭問題。論文中給出了一個(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類型的原子變量，load()會(huì)讀取變量的值，store()會(huì)設(shè)置變量的值。顯然，這段代碼希望在并發(fā)操作時(shí)，只返回一次Seal::Regular(...)，之后都返回Seal::None。但是，這里對(duì)原子變量的操作方法沒有正確的處理。如果有兩個(gè)線程同時(shí)執(zhí)行到if語句，并同時(shí)讀取到false結(jié)果，該方法可能給兩個(gè)線程都返回Seal::Regular(...)。 對(duì)該問題進(jìn)行修改后的代碼如下，這里使用了compare_and_swap()方法，保證了對(duì)原子變量的讀和寫在一個(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ù)競爭問題沒有涉及任何unsafe代碼，所有操作都在safe代碼中完成。這也說明了即使Rust語言設(shè)置了嚴(yán)格的并發(fā)檢查規(guī)則，程序員仍然要在編碼中人工保證并發(fā)訪問的正確性。

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

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

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

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

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

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

結(jié)論

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