Matthew Garrett，著名的核心開發者 Linux曾因其對自由軟體發展的貢獻而獲得自由軟體基金會獎項的某位人士，談到了SBAT（安全啟動高級目標）機制的本質。該機制旨在阻止引導程式中的漏洞，同時又不撤銷數位簽章。他也談到了SBAT在最近發生的更新事件中所扮演的角色。 Windows這導致某些發行版停止載入。 Linux與…並行安裝 Windows 在啟用了 UEFI 安全啟動的系統上會出現此問題。簡而言之，微軟和某些發行版的開發者都應為此負責，因為微軟沒有對更新進行充分測試，就將其應用到了不應該應用的系統上。 Linux當 GRUB 中發現漏洞時，它不會更新 GRUB 開機載入程式和 SBAT 產生編號。
以下是加勒特筆記的翻譯：
可以說，在開發 UEFI 安全啟動規範時，所有參與者都有點天真。安全啟動的基本安全模型是，在內核級別的特權環境中運行的所有代碼都必須在執行之前進行驗證 - 固件驗證引導程序，引導程序驗證內核，內核驗證運行時加載的任何其他內核代碼，現在我們有了一個值得信賴的環境來實施我們想要的任何其他安全政策。顯然，人們可能會犯錯誤，但規範提供了一種撤銷被發現不可信的簽名組件的方法：只需將不可信代碼的哈希值添加到變數中，然後拒絕加載具有該哈希值的任何內容，即使它是使用可信任金鑰簽署。
不幸的是，事實證明問題出在規模。每個分佈 LinuxGRUB（在安全啟動生態系統中運行的引導程式）會產生自己的引導程式二進位文件，每個文件都有自己的雜湊值。如果在這樣的引導程式的原始程式碼中發現漏洞，就必須重新載入大量不同的二進位檔案。用於儲存所有這些哈希值的變數的記憶體空間是有限的。每次發現 GRUB（最初編寫於安全啟動時代之前的引導程序，包含多個獨立的 .img 解析器和一個字體解析器）存在攻擊者執行任意代碼的新機制時，都添加一組新的哈希值顯然是不夠的，因此需要另一種解決方案。
這個解就是 SBAT。 SBAT 的整體概念非常簡單。引導鏈中的每個關鍵元件都聲明了包含在簽名二進位檔案中的安全性產生。當發現並修復漏洞時，這一代就會增加。然後可以發布定義最小代的更新 - 啟動元件將查看鏈中的下一項，將其名稱和代號與儲存在韌體變數中的名稱和代號進行比較，並根據該結果決定是否執行它。您可以發布一個更新，簡單地說：“任何安全生成低於此數字的 GRUB 版本都被視為不受信任”，而不是撤銷大量單獨的哈希值。
為什麼這件事突然變得重要起來了？ SBAT是由社區合作開發的。 Linux 微軟決定發布一項更新 Windows該指令告知系統不要信任安全等級低於特定等級的 GRUB 版本。這樣做是因為這些 GRUB 版本存在實際的安全漏洞，攻擊者可以利用這些漏洞破壞安全啟動鏈。 Windows我們已經看到一些惡意軟體試圖這樣做的真實案例（例如，Black Lotus 利用了引導程式中的一個漏洞）。 Windows但GRUB漏洞同樣有效）。從純粹的安全角度來看，這完全是合理的願望。
關於「出了點嚴重問題」的提示訊息以及更新後無法啟動的問題，這是 Shim 程式輸出的，並非微軟的程式碼。 Shim 程式會考慮 SBAT 更新，為了不違反系統中其他開機載入程式所遵循的安全性原則，儘管微軟發布了 SBAT 更新，但真正導致問題的是開機載入程式本身。 Linux 因此，它拒絕啟動舊版的GRUB。其他一切功能都正常。
人們遇到的問題是多種分佈 Linux 尚未發布採用新一代安全機制的 GRUB 版本，因此這些版本的 GRUB 被認為是不安全的（值得注意的是，GRUB 由發行版本身簽名，而非微軟簽名，因此不存在外部引入的延遲）。根據微軟的計劃，這次更新 Windows 本次更新本應僅將 SBAT 更新應用於僅運行該系統的系統。 Windows任何雙重啟動安裝都將始終容易受到攻擊，直到已安裝的發行版更新 GRUB 和 SBAT 版本為止。不幸的是，現在看來，這項更新並未如預期般運作，至少有些雙啟動系統應用了更新，但發行版的 Shim 卻拒絕載入 GRUB。
最終結果是什麼？微軟（出於顯而易見的原因）不想這麼做。 Windows 可能利用存在漏洞的 GRUB 版本進行攻擊，該版本可能被誘騙執行任意程式碼，然後將引導程式註入核心。 Windows 在啟動過程中。微軟透過發布更新實現了這一點。 Windows該更新更新了 SBAT 變量，以指示不應在這些系統上啟動存在漏洞的 GRUB 版本。 Shim 發行版提供的第一階段引導程式讀取了此變量，並從已安裝的 GRUB 副本中讀取了 SBAT 分區，發現兩者存在衝突，因此拒絕載入 GRUB，並顯示訊息「出了嚴重問題」。此更新原本不適用於雙啟動系統，但仍被套用了。
一般來說：
1) Microsoft 將更新應用到了不應該套用的系統。
2）一些分佈 Linux 當 GRUB 中發現漏洞時，沒有更新 GRUB 開機載入程式和 SBAT 安全性產生程式。
結果，有些人無法啟動他們的系統。我認為這裡有很多人應該受到指責。微軟應該做更多的測試，以確保可以準確地偵測到雙啟動安裝。但是提供簽名引導程式的發行版需要確保更新它們並更新安全生成以匹配，因為否則它們會提供可用於攻擊其他作業系統的攻擊向量，這有點違反了周圍的社會契約全部。
不幸的是，這裡的受害者主要是最終用戶，他們面臨著系統突然拒絕載入他們想要載入的作業系統的事實。這絕對不應該發生。我不認為詢問最終用戶是否需要安全啟動更新會產生好的結果，雖然我隱約傾向於認為 UEFI 安全啟動並不是讓大多數最終用戶受益的東西，但它也是您不希望看到的東西我不想在發生這樣的事件後找出答案，這就是為什麼我同情默認啟用它，所以我支持默認啟用它，並分享微軟的選擇，除了不幸的嘗試避免在雙重開機系統上更新。
總之，我深度參與了這機制的實施。 Linux 我在 2012 年編寫了 Shim 的第一個原型（現在它已經是一個性能顯著提升的引導加載程序，擁有更廣泛的用戶群體，而且我已經好幾年沒碰過它了），所以如果你想找人背鍋，請儘管怪我。這件事本來不該發生，除非你是微軟或某個發行版。 Linux那不是你的錯。我道歉。
來源： opennet.ru
