物聯網的迅速發展涌現了數十億與互聯網連接的無線嵌入式設備。 從醫療設備到坦克傳感器, 智能恒溫器, 智能路燈, 水監視器等等, 物聯網比以往任何時候都應用廣泛。

[[227532]]

會出什么問題呢？

大多數這些設備的設計都不像是被惡意攻擊的目標。 嵌入式系統傳統上被認為是穩定的產品, 但實施起來成本高昂, 因為投資回報率(ROI)在的周期比較長。 在過去一旦發貨, 就很少需要更新這些設備。 隨著智能手機和RTOS的爆發, 才使得固件更新以及應用更新的必要性凸顯出來。

假想一下, 惡意黑客將所有這些易受攻擊的連接設備作為潛在攻擊目標的話, 這些設備運行在不安全或過時的Linux 內核上, 有些漏洞還沒有被修補過, 并且可以被遠程控制！

這可不是一個有吸引力的場景。

[[227533]]

安全更新： 嵌入式與服務器的對比

如今, 升級安全問題驅動了IoT軟件的升級更新, 也提高了工程師添加新的功能和修復漏洞可能性。

對于嵌入式設備, 固件更新機制不僅必須是安全的, 而且是可靠的, 因為它要么成功更新, 要么失敗到可恢復狀態。 一般地, 很難在用戶現場升級固件，而需要在無人看管的情況下完成自動升級。 大多數更新也必須保留先前的設備狀態, 盡管在某些情況下恢復設備可能涉及將系統重新設置為默認狀態。

還有一個原子性問題。 Linux 服務器世界已經習慣于執行基于軟件包的更新, 所有的東西似乎都能運行良好。 但是嵌入式設備則不一定。

服務器通常運行在一個可控的環境中, 可能是安全的, 并且有電源的保障和網絡連接。 也就是說位于一個受監控的、可訪問的位置, 用戶干預恢復是可能的, 即使并不是必要條件。

Linux 服務器通常依賴于包管理, 基于 RPM (或 YUM)或基于 deb 的apt , 具有非原子增量更新的依賴辨識。 由包版本更新驅動流程, 每個都有一組復雜的預安裝腳本, 這些腳本可能會讓系統處于一個未定義的狀態, 甚至是非工作狀態。

不幸的是, 嵌入式設備可能無法訪問, 大部分時間可能處于低功耗模式, 有很長的存活周期, 可能會遭受電力或網絡中斷的困擾, 從而中斷固件升級。

總之, 基于包管理器的更新不是原子的, 因此很難測試和支持它們。 這通常會導致對設備固件實際狀態的跟蹤, 以及令人畏懼的"上次更新了什么?" 等問題。 這種方法不適合嵌入式系統, 因為這些系統會要求始終保持一致性。

[[227534]]

鏡像更新

更新嵌入式設備的傳統最佳方式是對鏡像進行整體更新。 在設備中, 這將是整個鏡像和所有的設備固件。 在嵌入式 Linux 設備中, 這通常轉化為分區更新, 所以分區方案是一個重要的考慮因素, 因為它將影響可以執行的軟件更新類型。

嵌入式 Linux 設備通常將媒介分為不同的分區, 可以分別更新:

• Bootloader 分區: 如果有的話, 很少更新, 更新嵌入式設備的引導程序最終將導致設備最終被退出。 因此, 完善的更新機制應盡可能避免這種情況。
• 引導 / 內核分區: Linux 內核和相關固件, 如設備樹和 initramfs 鏡像,除非為了安全，通常不需要更新。
• 根文件系統分區: 存儲的 OS 文件通常是只讀且不可變的。 這也很少更新, 但如果應用程序依賴于這里的庫, 可能會發生較多的更新情況。
• 用戶分區: 用戶應用程序的存儲位置和持久性數據是最需要更新的分區。

基本上, 固件鏡像更新可以從整個系統：內核、根和用戶分區到其中的某些部分。

有兩種可能的鏡像更新: 對稱和非對稱。

• 對稱: 對稱更新需要更新分區鏡像的雙重副本, 以便可以在另一個運行時完成更新。 這通常需要兩個引導/內核分區、兩個根文件系統以及兩個用戶分區。 然后, bootloader 會跟蹤哪些分區用于給定的引導。 對稱更新的停機時間很小, 通常只有重啟時間, 并允許更新取消。
• 非對稱: 非對稱更新使用了一個通常由內存運行的恢復操作系統, 它有一個 Linux 內核和 initramfs 鏡像。 這樣就減少了所需的分區數量, 因為恢復模式只在一個額外的分區中存在, 并且可以更新其他任何分區。 如果更新失敗, 可以重新嘗試恢復。 不對稱更新在更新時會有較長的下行時間, 并且不允許用戶取消。

用戶空間更新

通常情況下, 更新由用戶空間應用程序執行, 該應用程序可以獲取軟件更新包, 使用它, 并通知 bootloader 更新。 它還需要允許安裝后進行操作。 然后 bootloader 啟動一個硬件監視器并嘗試啟動。 如果引導成功, 那么硬件監視器就會被關閉; 如果不成功, 它就會被觸發, bootloader 再次嘗試啟動。 在多次嘗試之后, 它要么回到已知運行良好的分區, 要么進入恢復模式。

一個重要的考慮是, 用戶空間固件更新必須通過固件更新進程進行。 另一個風險是, 有可能更新到一個可啟動系統, 該系統具有一個已損壞的固件更新機制。 不幸的是, 需要回到 bootloader 或者其他恢復機制來更新固件。

有些系統使用 bootloader 來執行更新。 這存在嚴重的缺點， 如果固件更新代碼必須更新(例如因為分區更改) , 那么需要更新的是 bootloader, 這是非常危險的。 Bootloader 在驅動程序、工具、庫和它所支持的網絡協議數量方面也非常有限, 因此更新會發生在資源有限的環境中。

基于鏡像的開放源碼軟件更新有兩個主要選項, 分別支持對稱和非對稱更新:

• Swupdate[1] （GPLv2許可下)

swupdate 在 Yocto 通過 meta-swupdate 層(但僅限于對稱更新)來支持 swupdate。 它還包含一個 Mongoose web 服務器—— Suricatta daemon, 可以從一個遠程服務器上拉取 Eclipse HawkBit[2]提供的更新新(用于向終端設備執行軟件更新的后端解決方案)。 它目前只適用于 U-Boot bootloader。

• RAUC [3] （在 LGPLv2.1許可下）

RAUC 在 Yocto 通過 meta-ptx 層提供支持, 支持 Grub 或 Barebox bootloader。

[[227535]]

遠程鏡像更新

固件更新過程不僅能夠從本地來源(例如 FLASH、 USB、 SD 或 UART)完成更新, 還必須能夠遠程更新，即通常所說的OTA更新。 OTA更新使用遠程服務器向運行在設備上的客戶端推送更新。

開源遠程 OTA 固件更新的一些選項包括:

• Mender.io [4]（在 Apache 2 許可下）

mender.io同時用于客戶端和服務器。它是通過meta-mender層支持Yocto。服務器可以充當部署和構建管理器，但也可包含設備管理控制臺。

• Digi International Remote Manager [5], （在 MPLv2 許可下）

Digi 遠程管理器有一個基于云的專屬服務器和一個開源客戶端。 它通過 meta-digi 層在 Yocto 得到了支持。 服務器可以充當部署和構建管理器, 還包含一個設備管理控制臺, 該控制臺具有設備報告和監控功能。

• Eclipse HawkBit [2]（在Eclipse公共許可下）

Eclipse HawkBit 是一個 Eclipse公共許可證服務器, 同時充當部署和構建管理器, 以及具有設備報告和監視功能。

全量更新的問題通常是尺寸較大, 可能會導致資源的受限, 尤其是設備端帶寬的限制, 如蜂窩網絡。 差分驚喜固件更新是一個很好的妥協, 只傳輸前一版本的查分數據。

容器式更新

使用容器化程序簡化了軟件更新的用例, 應用程序可以單獨更新。

容器更新是建立在一個不可變的分發上(可能是只讀文件系統) , 其應用程序只存在于容器升級的容器中。

一些使用基于容器的固件更新的開源項目的例子有:

• Resin.io [6]

resin.io基于Docker的專有OTA更新服務器，遵從Apache 2 的許可，包括服務器和客戶端。它是通過meta-resin層來支持Yocto的。

• Ubuntu “Snappy” Core [7] 

Ubuntu Core 是一個基于 Ubuntu 的最小化操作系統, 它提供了與docker類的應用程序。

還有新的 OS 設計來支持 Docker 應用程序, 這些應用程序最終可能用于嵌入式空間, 如 CoreOS[8] 和 Project Atomic 9。

[[227537]]

增量二進制原子化OS更新

在嵌入式領域中，一個即將到來的趨勢是對每個文件的原子化增量更新, 可以快速部署或回滾, 同時保持完整的部署歷史。

一些開源項目:

• libOSTree [10] 

libOSTree 由一個庫和命令行工具組成, 定義為"操作系統二進制文件的 Git"。 它使用類似 git 的對象來存儲和部署 OS 查分包, 每個都有一個持久的數據副本。 對于使用它的 Yocto, 有一個 meta-updater 層，也被用于類似于 Atomic 的OS更新。

• swupd [11] 

swupd 最初是 ClearLinux 的一部分, 由英特爾贊助。 它非常類似于 libOSTree, 在 Yocto 通過 meta-swupd 層提供支持。

[[227538]]

選擇范圍

隨著物聯網設備的出現, 不僅固件更新是必要的, 而且新產品開發同樣必要。 固件更新策略的選擇需要盡早考慮, 因為這將影響到未來的產品設計決策。 與所有早期的決定一樣, 錯誤的選擇會給發展帶來沉重的負擔。

那些時間與市場緊密相連的項目可能會傾向于更傳統的、經過測試的、完整的固件更新策略。 這些包括通過 Yocto Project 的 meta-swupdate 層提供的各種技術, 以及像 Digi International 的 Remote Manager 這樣的為企業準備的 OTA 更新方案。

然而, 在新涌現的邊緣項目可以通過類似容器設計，來擴展整個系統固件的更新方法, 使應用程序能夠從系統更新中分離出來。

References:

[1] "SWUpdate: Software update for embedded system." SWUpdate: software update for embedded system — Embedded Software Update Documentation 2017.07 documentation. Accessed September 14, 2017. https://sbabic.github.io/swupdate/swupdate.html.

[2] Beaton, Wayne. "Eclipse hawkBit." Projects.eclipse.org. October 20, 2016. Accessed September 14, 2017. https://projects.eclipse.org/projects/iot.hawkbit.

[3] "Safe and Secure Updating!" Safe and secure embedded Linux updates | RAUC. Accessed September 14, 2017. http://rauc.io/.

[4] "Over-the-air software updates for embedded Linux devices." Open source OTA software updates for embedded Linux | Mender. Accessed September 14, 2017. https://mender.io/.

[5] "Digi Remote Manager?." Monitor and Manage Remote Connected Devices - Digi International. Accessed September 14, 2017. https://www.digi.com/products/cloud/digi-remote-manager.

[6] "Embedded software deployment done right." Home | Resin.io. Accessed September 14, 2017. https://resin.io/.

[7] Canonical. "Ubuntu Core." Ubuntu Core | Ubuntu. Accessed September 14, 2017. https://www.ubuntu.com/core.

[8] "CoreOS." CoreOS Blog ATOM. Accessed September 14, 2017. https://coreos.com/.

[9] "Building the Next Generation Container OS." Project Atomic. Accessed September 14, 2017. http://www.projectatomic.io/.

[10] OSTree. Accessed September 14, 2017. https://ostree.readthedocs.io/en/latest/.

[11] "Software update." Clear Linux Project. April 25, 2016. Accessed September 14, 2017. https://clearlinux.org/features/software-update.

編譯自http://www.embedded-computing.com/dev-tools-and-os/identifying-secure-firmware-update-mechanisms-for-embedded-linux-devices-and-open-source-options

 【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】

戳這里，看該作者更多好文