樂鑫esp32代理商:ESP RainMaker 特權隔離機制—案例研究,本案例研究以 ESP RainMaker 為例,展示了如何將 ESP 特權隔離機制部署至一個真實的物聯網應用程序。在前一篇文章中,我們介紹了 ESP 特權隔離機制,并借此在樂鑫esp32代理商 ESP32-C3 SoC 上實現了“用戶-內核”應用程序的相互隔離與獨立。目前,您可以通過多種方法在您的項目中部署 ESP 特權隔離機制。本案例研究以 ESP RainMaker 為例,展示了如何將 ESP 特權隔離機制部署至一個真實的物聯網應用程序。ESP RainMaker 是一個完整的 AIoT 平臺,可助力客戶快速開發 AIoT 產品。
在 ESP RainMaker 中部署 ESP 特權隔離機制
1. 創建項目目錄
如需應用 ESP 特權隔離機制,則項目的目錄結構將與常規 ESP-IDF 項目略有差異。ESP 特權隔離項目在創建目錄結構時,需要將程序放在兩個子目錄下:受保護的應用程序和用戶應用程序,并保證這兩個子文件夾中的應用程序均可被編譯系統編譯。以下為一個例子:
rmaker_switch
| — CMakeLists.txt
| — partitions.csv
| — protected_app/
| | — main/
| | — CMakeLists.txt
| | — protected_main.c
| — user_app/
| — main/
| | — CMakeLists.txt
| | — user_code.c
| — user_config.h
| — CMakeLists.txt
有關“目錄結構”的詳細說明,請見“ESP 特權隔離機制入門指南”文檔。
2. 安裝 ESP RainMaker 代理
根據系統調用的具體實現情況,我們可以選擇將 ESP RainMaker 代理安裝在兩個位置:
選項 1:用戶應用程序中
選項 2:受保護的應用程序中
在本文中,我們將以選項 2 為例,具體描述如何將 ESP RainMaker 代理安裝至受保護的應用程序文件夾中。
3. 劃分各組件至受保護應用程序和用戶應用程序
展示了各組件在受保護應用程序和用戶應用程序之間的分布情況。具體來說,所有庫(如 ESP RainMaker、TLS 棧等)因承擔了大部分繁重工作,都被放置在受保護的應用程序中;用戶應用程序則主要包括與業務相關的輕量級應用。構建系統將在 build 文件夾下生成 app_libs_and_objs.json 文件,該文件描述了所有庫、其占用的內存及對應應用程序中包括的 object 文件。
4. 實現系統調用
在本案例研究中,我們選擇將 ESP RainMaker 代理安裝在受保護的應用程序中。這種情況下,我們必須為 ESP RainMaker 提供的所有公共 API,增加一個自定義系統調用。得益于 ESP 特權隔離機制非常易于擴展,因此增加這樣一個自定義系統調用并不復雜,詳見這里。接下來,我們將以樂鑫esp32代理商 ESP RainMaker 的公開 API esp_rmaker_start() 為例,展示如何為其增加一個自定義系統調用。我們需要把 ESP RainMaker 移動至受保護的應用程序中。此后,用戶應用程序中所有對 esp_rmaker_start() 的調用均將通過我們增加的自定義系統調用接口完成。
具體過程描述如下:
a. 我們需要在用戶應用程序中實現一個系統調用包裝程序 (wrapper),名稱即為系統調用程序名加一個 usr_ 前綴。此后,這個包裝程序將通過宏 EXECUTE_SYSCALL 生成一個同步異常,并通過該異常進入受保護空間。宏 __NR_esp_rmaker_start 即為構建系統生成的系統調用號。
esp_err_t usr_esp_rmaker_start(void)
{
return EXECUTE_SYSCALL(__NR_esp_rmaker_start);
}
注意:構建系統已經將 esp_rmaker_start 關聯至 usr_esp_rmaker_start,因此用戶應用程序調用 esp_rmaker_start即可完成系統調用。
b. 接著,我們需要實現一個受保護應用程序的系統調用處理程序 (handler)。此后出現同步異常即可觸發該處理程序,繼而調用實際 API,并將錯誤代碼返回給用戶空間。
esp_err_t sys_esp_rmaker_start(void)
{
return esp_rmaker_start();
}
c. 為了綁定用戶和受保護系統調用的實現,我們需要在 example 目錄 (examples/rmaker_switch/components/rmaker_syscall/rmaker_syscall.tbl) 下創建一個自定義系統調用表。此時,我們需要定義四個屬性:
唯一的系統調用號
common / custom 屬性標志
系統調用名
受保護的系統調用處理程序名
1289 common esp_rmaker_start sys_esp_rmaker_start
此后,構建系統將通過這個系統調用表文件,來創建一個 __NR_esp_rmaker_start 宏。這個宏可以將用戶應用程序的 EXECUTE_SYSCALL 調用綁定至受保護應用程序的 sys_esp_rmaker_start。
以上示例僅用于演示,具體實現請見 rmaker_syscall。
5. 實現用戶應用程序
在完成這些系統調用實現后,我們可以在用戶應用程序中使用 ESP RainMaker 提供的幾乎所有公共 API。目前,我們已經使用受保護應用程序中添加的服務,實現了一個 IoT 開關應用程序,詳見 GitHub repo。
在樂鑫esp32代理商 ESP32-C3 SoC 上運行應用程序
1. ESP RainMaker 代理的初始化
首先,用戶應用程序在啟動代碼注冊 heap 和 console 后,將控制權移交給 user_main。接著,user_main 函數將初始化 ESP RainMaker 代理,創建一個 RainMaker 設備,并通過系統調用接口在受保護的應用程序中啟動 ESP RainMaker 代理。受保護的應用程序管理 Wi-Fi 連接,并提供所有 RainMaker 服務。
2. ESP RainMaker 的云連接
一旦完成 Wi-Fi 配網和連接,受保護的應用程序將與 RainMaker 云建立 TLS 連接。在此之后,我們的 ESP32-C3 設備已準備好接收來自云端的事件。受保護的應用程序接收所有云事件,并根據配置觸發用戶空間回調。
未來計劃
在不改變受保護應用程序(RainMaker 內核)的前提下,單獨升級用戶應用程序,進而針對業務邏輯變化,輕松更新業務應用程序,即使頻繁更新也并不麻煩。
受保護的應用程序與 RainMaker 云建立 TLS 連接。如果用戶應用程序崩潰,TLS 連接也不受影響,受保護的應用程序仍可以向 RainMaker 云發送實時調試信息。
總結
1.我們實現了一個由受保護應用程序提供的系統調用接口,來提供 RainMaker 服務。
2.我們集成了上游 ESP RainMaker 應用程序,且集成過程的改動需求極低。
3.我們對比了傳統 ESP RainMaker 應用程序和 ESP 特權隔離應用程序的 bin 文件大小和靜態內存使用情況。