摘要：近幾年，Rust語言以極快的增加速度得到了大量關注。其特色是在保證高安全性的同時，得到不輸C/C++的性能。在Rust被不少項目使用之後，其實際安全性表現到底如何呢？
近幾年，Rust語言以極快的增加速度得到了大量關注。其特色是在保證高安全性的同時，得到不輸C/C++的性能，讓系統編程領域可貴的出現了充滿但願的新選擇。在Rust被不少項目使用之後，其實際安全性表現到底如何呢？今年6月份，來自3所大學的5位學者在ACM SIGPLAN國際會議（PLDI'20）上發表了一篇研究成果，針對近幾年使用Rust語言的開源項目中的安全缺陷進行了全面的調查。git
這項研究調查了5個使用Rust語言開發的軟件系統，5個被普遍使用的Rust庫，以及兩個漏洞數據庫。調查總共涉及了850處unsafe代碼使用、70個內存安全缺陷、100個線程安全缺陷。程序員
在調查中，研究員不光查看了全部漏洞數據庫中報告的缺陷和軟件公開報告的缺陷，還查看了全部開源軟件代碼倉庫中的提交記錄。經過人工的分析，他們界定出提交所修復的BUG類型，並將其歸類到相應的內存安全/線程安全問題中。全部被調查過的問題都被整理到了公開的Git倉庫中： https://github.com/system-pclub/rust-studygithub
內存安全問題的分析
這項研究調查了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語言中的典型問題，創建新的缺陷檢測工具。