近期，Linux內(nèi)核社區(qū)經(jīng)歷了一場(chǎng)驚心動(dòng)魄的風(fēng)波，6.13版本的發(fā)布差點(diǎn)因微軟貢獻(xiàn)的代碼問(wèn)題而受阻。幸運(yùn)的是，得益于Intel與AMD的迅速介入，這場(chǎng)危機(jī)得以化解。
事件的起因在于微軟提交的一段與ARCH_HAS_EXECMEM_ROX內(nèi)核配置相關(guān)的代碼。這一配置旨在提升x86_64及AMD64架構(gòu)的性能，通過(guò)啟用只讀執(zhí)行（ROX）權(quán)限，優(yōu)化可執(zhí)行內(nèi)存（EXECMEM）的使用。然而，這段關(guān)鍵代碼在未經(jīng)x86內(nèi)核維護(hù)者審核的情況下被推送至內(nèi)核倉(cāng)庫(kù)，從而引發(fā)了一系列連鎖反應(yīng)。
問(wèn)題的核心在于，未經(jīng)確認(rèn)的代碼破壞了控制流完整性（CFI）機(jī)制。CFI作為一項(xiàng)重要的安全功能，通過(guò)影子堆棧和間接分支目標(biāo)（IBT）技術(shù)，有效抵御了返回導(dǎo)向編程（ROP）及調(diào)用/跳轉(zhuǎn)導(dǎo)向編程（COP/JOP）等高級(jí)攻擊手段。影子堆棧通過(guò)比對(duì)硬件存儲(chǔ)的副本，確保返回地址的準(zhǔn)確無(wú)誤，從而防止惡意軟件篡改合法軟件的執(zhí)行流程。
面對(duì)這一突發(fā)狀況，Intel的Peter Zijlstra迅速行動(dòng)，提交了緊急修復(fù)補(bǔ)丁。他在補(bǔ)丁中指出，微軟的代碼不僅導(dǎo)致了alternative.c文件的嚴(yán)重混亂，還存在多處錯(cuò)誤，部分CFI變體甚至可能引發(fā)系統(tǒng)崩潰，對(duì)系統(tǒng)的穩(wěn)定性和安全性構(gòu)成了嚴(yán)重威脅。
AMD的Borislav Petkov同樣對(duì)此事表達(dá)了強(qiáng)烈的不滿。他批評(píng)道，如此重要的代碼更改，竟然在未經(jīng)任何x86維護(hù)者確認(rèn)的情況下就被合并，這不僅違反了內(nèi)核開(kāi)發(fā)的常規(guī)流程，也暴露出了項(xiàng)目管理上的嚴(yán)重漏洞。這一事件再次提醒了開(kāi)源社區(qū)，代碼審核與質(zhì)量控制的重要性不容忽視。
此次事件雖然最終得以平息，但留給Linux內(nèi)核社區(qū)的教訓(xùn)卻是深刻的。它再次強(qiáng)調(diào)了代碼審核流程的重要性，以及開(kāi)源社區(qū)在面對(duì)外部貢獻(xiàn)時(shí)，必須保持高度的警惕性和嚴(yán)謹(jǐn)性。只有這樣，才能確保Linux內(nèi)核的持續(xù)穩(wěn)定與安全，為廣大用戶提供更加可靠的服務(wù)。
