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