2022 - 6.0 與 Rust 核心（記憶體安全的進場）#

案件摘要#

2022 年 10 月，Linux 6.0 發布；2022 年 12 月（6.1），Rust 語言支援正式進入 Linux 核心——

\[ \text{6.1（2022.12）}:\; \text{Rust 核心模組首次進入主線}. \]

C 語言寫核心 50 年（1973 年 Unix 以 C 重寫起）後，第一個記憶體安全語言進場——為了彌補 C 的記憶體安全缺陷（buffer overflow、use-after-free）。

前因 -- 為什麼會有這個案子#

C 的安全缺陷：微軟與 Google 的統計顯示，約 70% 的嚴重資安漏洞是記憶體安全問題（buffer overflow、use-after-free、雙重釋放）——C 的指標設計無法在編譯期排除。
Rust 的理論基礎：所有權系統（ownership）+ 借用檢查（borrow checker）——在編譯期證明無資料競態、無懸垂指標、無記憶體洩漏：

\[ \text{每份資料} = \text{唯一所有者} \;\wedge\; \text{借用不可變/可變互斥} \;\Rightarrow\; \text{編譯期記憶體安全}. \]

2020 年的提議：Google 的 Josh Triplett 等在 Linux Plumbers Conference 提議 Rust 支援；Torvalds 表態支持（「不再是 30 年前的疑慮」）；Miguel Ojeda 主導實作。

線索與推理 -- 技術面貌（2022+）#

技術	狀態	版本年份脈絡	彌補的缺陷
Rust 核心	6.1（2022.12）	試驗性支援	C 的 70% 記憶體安全漏洞
Rust 驅動	6.8（2024.3）：first real driver（Phy 網卡驅動）	Rust 從試驗到實戰	C 驅動的 UAF 漏洞
EEVDF 排班	6.6（2023.10）	取代 CFS（2007）	CFS 無延遲敏感度
io_uring 進化	6.0 世代	network zero-copy	系統呼叫開銷
MGLRU	6.1（2022.12）	多代 LRU 記憶體回收	舊 LRU 的掃描低效

Rust 範例：核心模組（記憶體安全的實證）#

// Linux 核心 Rust 模組 (6.1, 2022)
use kernel::prelude::*;

module! {
    type: HelloKernel,
    name: "hello_kernel",
    license: "GPL",
}

struct HelloKernel;

impl kernel::Module for HelloKernel {
    fn init(_module: &'static ThisModule) -> Result<Self> {
        pr_info!("Hello from Rust in the Linux kernel!\n");
        Ok(HelloKernel)
    }
}

（借用檢查器在編譯期拒絕 use-after-free——C 需要跑 fuzzer 找的 bug，Rust 編譯不過。）

Rust 範例：所有權 vs C 指標的對照#

// Rust：編譯期就擋下 use-after-free
fn main() {
    let v = vec![1, 2, 3];
    let r = &v[0];        // 借用 v
    // drop(v);           // 編譯錯誤！借用還在使用中
    println!("{}", r);    // 安全——借用檢查器證明無懸垂
}

// C：同樣的 bug 編譯通過、執行期爆炸
int main(void) {
    int *p = malloc(sizeof(int) * 3);
    free(p);
    *p = 42;              /* use-after-free——編譯器不吭聲 */
    return 0;             /* 這就是 70% 資安漏洞的根源 */
}

Python 範例：EEVDF 排班（2023，6.6）的概念#

# EEVDF (2023, 6.6)：在 CFS 的公平上加入「延遲敏感度」
class Task:
    def __init__(self, pid, weight, deadline):
        self.pid, self.weight = pid, weight
        self.deadline = deadline   # 越早的 deadline 越優先
        self.vruntime = 0.0

def eevdf_pick(tasks):
    """vruntime 最小者中，deadline 最早者先跑"""
    eligible = [t for t in tasks if t.vruntime <= min(x.vruntime for x in tasks) + 1]
    return min(eligible, key=lambda t: t.deadline).pid

tasks = [Task("audio", 1024, 5), Task("batch", 1024, 100)]
print(eevdf_pick(tasks))   # "audio"——延遲敏感的行程優先

Shell 範例：MGLRU 與 6.x 的實證#

# MGLRU (6.1, 2022)：記憶體回收的現代化
$ cat /sys/kernel/mm/lru_gen/enabled
0x0007    # MGLRU 已啟用——低記憶體時掃描更少、回應更快

# Rust 核心：查看 Rust 驅動（6.8+）
$ lsmod | grep rust
$ dmesg | grep -i rust

結案 -- 後果與影響#

Rust 的擴張：6.8（2024.3）第一個 Rust 驅動（Phy 網卡）；Rust for Linux 專案持續擴張——核心驅動的記憶體安全化進行中。
整個產業的跟進：Windows（2023 起 Rust 進入 Windows 核心）、Android（Rust 成為系統組件）——記憶體安全成為系統語言的新標準。
EEVDF（2023）：CFS（2007）的接棒——公平性 + 延遲敏感度的排班理論進化。
歷史的呼應：1973 年 Ritchie 用 C 重寫 Unix 是「可移植性的革命」；2022 年 Rust 進入 Linux 是「記憶體安全的革命」——每隔 50 年，系統語言換一次血。
歷史教訓：當一類 bug（記憶體安全）佔漏洞 70%，就該換語言而非加修補——Rust 進場是 50 年一遇的核心語言革命。

關鍵人物與文獻#

M. Ojeda：Rust for Linux (2022, 6.1)。
L. Torvalds：支持 Rust 進場（2022）。
P. Turner（Google）：EEVDF 排班 (2023, 6.6)。
相關案件：2007-CFS排班與2.6.23.md、../UNIX/1973-Unix以C重寫與管道.md。