本文將討論在連接的設備中更新引導加載程序的問題。所討論的原則適用于任何軟件系統，我們將專門討論運行 linux 的系統。

現代電子設備越來越復雜，并與互聯網連接。作為一般規則，復雜性與安全性背道而馳，不安全的互聯網連接設備已經成熟，罪魁禍首可以濫用。在設計這些系統時，我們必須假設所有軟件都會有錯誤，其中一些錯誤將是可利用的漏洞。解決這些問題的第一步是確保軟件更新可以傳送到您的系統，最好是自動和無線 （OTA）。歐盟“消費者物聯網網絡安全：基線要求”標準草案 （ETSI EN 303 645），”具體包括及時、自動更新作為其要求之一。它確實為不可變的第一階段引導加載程序例外，以最大程度地降低現場設備處于非引導狀態（也稱為“磚塊 ”板）的風險。

本文將討論更新連接設備中的引導加載程序的問題。請注意，雖然這里討論的原則適用于任何軟件系統，但我們將專門討論運行 Linux 的系統。使用更小、更定制設計的系統可能會為這些系統提供更多獨特的選擇。

系統設計

圖 1 顯示了一個通用的 Linux 系統，其中包含可能更新的主要組件。存儲介質將是某種塊設備，例如 eMMC 或 SATA 硬盤驅動器。在該設備中，將有引導加載程序、內核、設備樹（取決于所使用的 CPU）和包含構建系統所需的所有文件的根文件系統。在某些情況下會使用更復雜的架構，但出于討論的目的，我們將其限制為最簡單的情況。

諸如 Mender 、 swupdate等系統更新實用程序能夠開箱即用地更新內核、設備樹和根文件系統，并且在許多情況下，這種級別的可更新性就足夠了。

引導加載程序是系統的組件，負責在上電時初始化系統，從 CPU 復位指令開始。它負責以下任務：

？ 初始化和清理 RAM

？ 設置電源軌和時鐘

？ 將所有外設設置為已知的靜止狀態以避免意外中斷。

？ 加載并啟動 Linux 內核

如前所述，所有軟件都有錯誤，因此我們可以假設也會有引導加載程序錯誤。我們可以通過最小化引導加載程序的功能來減少攻擊面，但是我們可以完全消除錯誤的風險。為什么更新引導加載程序比更新系統的其他組件更復雜？如果我們嘗試有什么風險？如果我們不嘗試會有什么風險？

具有無線功能的系統

此框圖顯示了能夠進行強大的無線 （OTA） 更新的系統的基本系統設計。［4］ 引導加載程序負責系統初始化并與 OTA 客戶端交互以選擇使用哪個內核、設備樹和根文件系統。穩健性是通過具有運行 Linux 映像所需的組件的完全冗余來提供的。這可確保在 OTA 更新中斷的情況下始終有一個已知良好的映像可以回滾。此外，這確保了完全原子更新，因為更新客戶端是系統中唯一知道更新正在進行中的組件，直到更新完成并準備好運行。

OTA 更新的任何組件都可能導致設備無法正常工作，因此系統的穩健性與引導加載程序處理回滾到先前已知良好配置的能力直接相關。這意味著系統中必須有一個組件，它是不可變的以正確處理錯誤的更新。

引導加載程序更新

在大多數情況下，處理回滾的不可變組件是引導加載程序。在一個典型的嵌入式 Linux 應用程序中是Das U-Boot ［5］。如果我們嘗試更新引導加載程序，由于沒有冗余，我們就有可能使我們的電路板變磚。如果在我們開始寫入新的引導加載程序映像之后，但在寫入完成之前，板電源循環，那么我們的映像包含舊版本的一部分和新版本的一部分。這種情況下的行為是未定義的，唯一的緩解措施是能夠物理訪問設備以編寫正確的引導加載程序，通常使用 USB 或其他硬接線連接。

但是我們為什么要更新引導加載程序呢？至少，引導加載程序只是用作初始化硬件然后將控制權交給 Linux 內核的一種方式。由于功能有限，引導加載程序出現問題的風險已降至最低。

對于許多設計，這種風險水平是可以接受的，架構師可以決定在其部署的設備中不提供 OTA 引導加載程序更新。作為最后的手段，仍然可以使用硬連線機制。

然而，對于許多設計來說，這種風險水平被認為是不可接受的，并且必須為引導加載程序的 OTA 更新提供一些機制。此外，許多設計在引導加載程序中添加了更多功能；系統診斷或其他特定于應用程序的要求可能會在引導加載程序中實現，從而導致需要更新的可能性更大。那么我們該如何處理呢？

提供引導加載程序更新的選項

有許多選項可以更新引導加載程序。本討論并非旨在提供完整的解決方案，而是對可能適用于您的設計的方法進行高級描述。每個都有其權衡。

選項 1：無冗余

如果特定應用程序可以接受磚塊板的風險，那么您可以簡單地嘗試部署引導加載程序更新 OTA，并在它發生時處理后果。如果您的車隊規模很小，并且物理訪問設備的成本很低，那么這可能會很好。如果需要更新引導加載程序，并且 OTA 嘗試失敗，那么您的嘗試并不會更糟。OTA 引導加載程序更新失敗的情況與沒有 OTA 引導加載程序更新能力的情況相同。即，您必須獲得對設備的物理訪問權限并使用制造商提供的機制來重新刷新引導加載程序。

選項 2：多階段引導加載程序

此架構將引導加載程序功能分為兩個階段（或更多階段，具體取決于您的設計的復雜性）。最終，這仍然需要在階段 1 中使用不可變的代碼。您在更新階段 2 時確實具有冗余性和穩健性，因此如果您仔細選擇在何處實現功能，您可以提供引導加載程序功能的 OTA 更新。這是一個不錯的選擇，因為不可變的第一階段二進制文件中的代碼量減少了，從而降低了整體風險。

U-Boot 使用 SPL（Secondary Program Loader）和 TPL（Tertiary Program Loader）實現多階段引導。引入此機制是為了支持具有單獨引導 ROM 的系統，這些引導 ROM 太小而無法存儲完整的 U-Boot 映像。在這種情況下，U-Boot SPL 映像將包含足夠的初始化代碼來加載和啟動完整的 U-Boot 映像，通常來自 MMC 等大型塊設備。SPL 需要能夠初始化足夠的 RAM 和包含完整 U-Boot 映像的設備。

即使對于沒有小型引導 ROM 限制的設備，我們也可以利用這種架構在第 2 階段實現我們的可更新功能，同時在第 1 階段保留最低限度，包括正確處理冗余塊。

第 1 階段存在問題，需要物理訪問才能解決。鑒于第 1 階段的功能減少，在許多情況下，這種風險水平是可以接受的。

選項 3：并行引導加載程序

許多板提供從多個設備啟動的能力。例如，許多板可以從板載 eMMC 或可移動 SD/MMC 卡啟動。或者，他們可以為引導加載程序使用專用的 NOR 閃存設備，但仍然能夠從 eMMC 塊媒體運行引導加載程序。

這些類型的板可以配置為將不可變引導加載程序存儲在一個受支持的設備中，然后將 OTA 可更新引導加載程序存儲在另一個設備中。通常，可更新的引導加載程序與根文件系統位于相同的媒體（即 eMMC）中，因此很容易更新。由于“備用”媒體中的引導加載程序是不可變的，因此可以依靠它從“標準”位置的引導加載程序的損壞 OTA 更新中恢復。

這種方法的問題是引導設備的選擇通常需要物理訪問電路板以移動跳線或更改開關設置。如果您的設備位于最終用戶可以訪問它們的位置，這可能是一個可行的選擇，因為最終用戶可以在出現故障時選擇恢復媒體。這可以通過文件或支持人員的指示來完成。

一些系統使用外部硬件來選擇引導加載程序。運行 RTOS 的小型 MCU 可以監控適當的系統活動，并在 Linux 系統未運行的情況下選擇備用引導加載程序。使用外部源正確檢測這可能會很棘手，但切換 GPIO 引腳或寫入共享內存的看門狗定時器可能就足夠了。這也是一個更復雜的設計，需要根據您的系統要求進行考慮。請注意，您可能需要考慮對 MCU 固件映像進行 OTA 更新，這是另一個復雜程度。

選項 4：eMMC 引導分區

eMMC ［6］規范的 4.3 版需要 2 個單獨的硬件引導分區。這些分區通常為每個 4MB，用于存儲引導加載程序。這些分區在 Linux 用戶空間是可讀寫的，但默認情況下它們是只讀的；通過寫入 /sys 偽文件系統中的文件來啟用讀寫功能：

曼德的方法

利用 eMMC 引導分區，對分區的更新是原子的，并且獨立于對根文件系統的更新。eMMC 引導分區之間沒有自動故障轉移，因此這并不能減輕由于引導加載程序更新失敗而導致設備變磚的問題。但是，這確實可以輕松地為引導加載程序提供更新，而無需為根文件系統進行任何特定調整。

由于在提供引導加載程序更新時存在板卡風險和 OTA 更新過程的穩健性降低，Mender 不提供開箱即用的引導加載程序更新。正如所討論的，很難以通用的方式進行，并且最終可能會非常特定于應用程序和硬件。Mender更新模塊框架允許插件架構支持自定義更新類型。Mender 可以使用自定義更新模塊支持任何任意有效負載類型。此插件架構允許提供處理特定負載類型的自定義腳本。允許在特定系統中更新引導加載程序可以使用更新模塊來實現。 根據應用程序的需要以及所用硬件的能力，可以使用上述任何一種方法。

包起來

在現場部署的設備中上傳系統引導加載程序存在許多風險。不合時宜的電源故障可能會使設備在現場陷入困境，從而導致潛在的昂貴的召回過程。但是，不提供引導加載程序更新機制可能會帶來不可接受的風險，具體取決于特定應用程序的配置文件。我們介紹了許多允許引導加載程序更新的方法，并討論了每種方法的優缺點。這有望讓您作為系統設計人員為您的系統做出適當的選擇，并幫助您在適當了解設計風險的情況下快速進入市場。

審核編輯：郭婷