北京
過去幾周，一位專注于長期Rust基礎設施項目的開發者一直在做一件事：為未來的組件構建一個極簡的內核層，然后不斷進行壓力測試。他的焦點非常窄——只關注那些最基礎的原語，確保它們在哪怕最極端的輸入下也不會出錯。隨后，他發起了一輪大規模的對抗性模糊測試，目標是這些內核原語。到停止時，這次測試的引擎已經累計執行了大約148億次。
起初，引起他注意的不過是幾個純粹的內存崩壞，看起來像是低級的越界或者未定義行為。但當第二個異常中斷出現時，性質完全變了——它不是一個典型的內存錯誤。模糊器最終停在了這樣一個斷言失敗上：累加偶數哈希與零哈希的比較沒有通過，換句話說，檢測代碼認為偶數次異或的結果應該是零，但實際并不相符。這個斷言失敗乍一看，像是指向了哈希原語中基于異或的實現層存在嚴重缺陷。對于一個依賴于代數確定性保證的低級內核基礎層來說，如果真是這樣，后果會很棘手。
但排查的結果指向了一個更隱蔽的方向。模糊目標中設計了一段壓力驗證，其構造可以簡化為：先將一個累加器初始化為哈希值h，然后在八次循環中，每次把累加器和同一個哈希值h再做一次異或。原先被當作正確前提的不變量，是“偶數次異或操作必然回到零哈希”。表面上看，如果累加器從一開始的零值參與運算，八次異或之后確實等于零；可這里的累加器啟動時已經拿著h了。也就是說，實際執行序列是：h，異或h得到零，再異或h得到h，再異或h回到零……一共九次異或參與運算，奇數次異或的結果是h，不是零。XOR的奇偶校驗法則極其嚴格，少一次或者多一次，最終狀態完全不同。
明白了這一點，反推回來的結論就清晰了許多：該原語本身的實現是正確的，真正出錯的是驗證邏輯里那條“偶數次異或應歸零”的假設。這個反思不是小事。在低級系統中，構建基礎組件的工程師常常會為每一段確定性原語設計配套的驗證層，如果驗證層里埋著自以為成立的假設，它不光會把正確的代碼判定為異常，還會在整個基礎設施里制造出很難定位的困惑。開發者后來把累加器的初始化改為零哈希，并維持八次異或操作，這樣一來奇偶校驗與零值檢查共同成立，不變量才在數學意義上完全正確。
這件事也折射出一個長期寫基礎設施軟件才能體會到的經驗：絕大多數嚴重事故，壓根不是來自那些看著就很復雜的代碼分支。它們更多地，是從一些小到不堪一擊的假設里生長出來，這些假設能夠沉默地穿過代碼審查、集成測試甚至資深工程師的直覺判斷，直到某一天在極端上下文中被觸發。模糊測試之所以成為基礎設施開發中的稀缺武器，原因不在于它能夠發現人類肉眼原本就看得到的崩潰，而在于它可以持續且殘忍地逼迫那些沉在底層邏輯里的假設，一個接一個顯形。
有時候，最值錢的那個“缺陷”，恰恰不是把原語寫錯了，而是證明了原語一直都對，但你認為它錯的理由是錯的。對于追求長期穩定性的內核底層來說，這樣的發現遠比修復某個局部漏洞更關鍵，也更需要耐心。148億次執行背后，不是算力的炫耀，而是一種方法論的提醒：在驗證基礎設施的那一刻，先把你對“正確”的假設也當作需要被審計的目標。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
