微軟看上的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>>
    let result = connect(client.read().unwrap().m);
    match result {
        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 程式碼

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

修改以後，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語言中的典型問題，建立新的缺陷檢測工具。

點選這裏→瞭解更多精彩內容