物聯(lián)網(wǎng)的迅速發(fā)展涌現(xiàn)了數(shù)十億與互聯(lián)網(wǎng)連接的無線嵌入式設(shè)備。 從醫(yī)療設(shè)備到坦克傳感器, 智能恒溫器, 智能路燈, 水監(jiān)視器等等, 物聯(lián)網(wǎng)比以往任何時候都應(yīng)用廣泛。

[[227532]]

會出什么問題呢？

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

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

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

[[227533]]

安全更新： 嵌入式與服務(wù)器的對比

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

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

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

服務(wù)器通常運行在一個可控的環(huán)境中, 可能是安全的, 并且有電源的保障和網(wǎng)絡(luò)連接。 也就是說位于一個受監(jiān)控的、可訪問的位置, 用戶干預(yù)恢復(fù)是可能的, 即使并不是必要條件。

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

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

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

[[227534]]

鏡像更新

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

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

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

基本上, 固件鏡像更新可以從整個系統(tǒng)：內(nèi)核、根和用戶分區(qū)到其中的某些部分。

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

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

用戶空間更新

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

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

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

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

• Swupdate[1] （GPLv2許可下)

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

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

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

[[227535]]

遠程鏡像更新

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

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

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

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

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

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

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

Eclipse HawkBit 是一個 Eclipse公共許可證服務(wù)器, 同時充當部署和構(gòu)建管理器, 以及具有設(shè)備報告和監(jiān)視功能。

全量更新的問題通常是尺寸較大, 可能會導(dǎo)致資源的受限, 尤其是設(shè)備端帶寬的限制, 如蜂窩網(wǎng)絡(luò)。 差分驚喜固件更新是一個很好的妥協(xié), 只傳輸前一版本的查分數(shù)據(jù)。

容器式更新

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

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

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

• Resin.io [6]

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

• Ubuntu “Snappy” Core [7] 

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

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

[[227537]]

增量二進制原子化OS更新

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

一些開源項目:

• libOSTree [10] 

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

• swupd [11] 

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

[[227538]]

選擇范圍

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

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

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

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專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】

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