RFC-0244：提高使用者定義的 Zircon 例外狀況

RFC-0244：引發使用者定義的 Zircon 例外狀況
狀態已接受
領域
  • 核心
說明

加入 syscall，可引發使用者定義的 Zircon 例外狀況
毛皮變化
作者
審查人員
提交日期 (年-月-日)2024-03-22
審查日期 (年-月-日)2024-04-22

編輯此 RFC

編輯 RFC 中繼資料

摘要

此 RFC 導入了 zx_thread_raise_exception Syscall，它會引發 使用者定義的 Zircon 例外狀況。此 Syscall 的第一個用途是 當其中一個程序呼叫 exec() 時，Starnix 就會向偵錯工具發出信號。 偵錯工具會根據這個信號來判斷開發人員是否 附加至程序

提振精神

在 Starnix 中執行程序時，我們通常會想以程序的名稱做為程序名稱 指定是否要將偵錯工具附加到該程序。這個 才是最有效的做法。 檢查現有程序的 ZX_PROP_NAME，找出需要的程序。 不過，這個方法對於目前還未提供 這是因為 Starnix 程序是由 fork() 建立，因此 ZX_PROP_NAME 與呼叫 fork() 的程序名稱相符。Starnix 變更 exec() 期間程序的 ZX_PROP_NAME，但偵錯工具 偵測作業不會附帶通知，因此不會附加至程序。

相關人員

誰會負責確認 RFC 是否已獲接受？(這個部分為選填，但 encouraged.)

講師：

FEC 任命的人員，透過 RFC 處理此 RFC 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作

審查者：

  • cpu@google.com
  • jamesr@google.com
  • jruthe@google.com

諮詢：

列出應審查 RFC，但不需經過核准的人員。

社交功能：

我們在 Zircon 聊天管道中討論了這個問題 我曾請我建議他們製作原型 透過命名方式，將 ID 附加至尚未執行的 Starnix 程序 使用者定義的例外狀況

需求條件

  1. 當 Starnix 程序呼叫 exec() 時，偵錯工具必須收到通知， 它可以檢查程序是否符合任何篩選器 (例如 程序的新名稱是否與名稱篩選器相符)。
  2. 如果沒有，則通知機制不應耗用大量資源 偵錯工具正在執行
  3. 通知機制必須處理多個偵錯代理程式的情況 就能同時執行多項作業
  4. 設計時，不應要求我們變更系統的其他部分 (例如 crashsvc)。

設計

偵錯工具會監聽 ZX_EXCP_PROCESS_STARTING 個例外狀況 ZX_EXCEPTION_CHANNEL_TYPE_JOB_DEBUGGER。這個 RFC 的做法是 方法是將其他類型的例外狀況傳送至 ZX_EXCEPTION_CHANNEL_TYPE_JOB_DEBUGGER。

很抱歉，我們不希望 Zircon 自動產生例外狀況 程序的 ZX_PROP_NAME 屬性變更時 (該屬性可以 只能由任意執行緒變更相反地，我們希望 所產生。幸運的是 Starnix 總是在處理程序中從執行緒變更程序名稱， 透過 exec() 或是只能在內部從內部寫入的 procfs 檔案 一個程序

因此，我們引進了新的 sys 呼叫，以產生使用者定義的 例外狀況。每當 Starnix 變更程序名稱時，Starnix 都會使用 才能引發這類例外狀況偵錯工具會監聽 例外狀況，然後重新掃描附加篩選器清單，查看使用者是否想要 以新名稱對程序進行偵錯。

使用者定義的例外狀況

與 Zircon 物件上的使用者定義信號類似，這個 RFC 保留部分的 Zircon 例外狀況命名空間以取得使用者定義的例外狀況。這個預留項目 確保使用者定義的例外狀況不會與之後的 系統定義的例外狀況

具體來說，這個 RFC 會使用 ZX_EXCP_SYNTH 定義新的 zx_excp_type_t 位元設定 ZX_EXCP_USER：

#define ZX_EXCP_USER                    ((uint32_t) 0x309u | ZX_EXCP_SYNTH)

這個 RFC 也定義了一些知名的使用者例外狀況代碼，這些代碼會顯示在 zx_exception_context_t 中的 synth_code 欄位。

ZX_EXCP_USER_CODE_PROCESS_NAME_CHANGED  ((uint32_t) 0x0001u)
ZX_EXCP_USER_CODE_USER0                 ((uint32_t) 0xF000u)
ZX_EXCP_USER_CODE_USER1                 ((uint32_t) 0xF001u)
ZX_EXCP_USER_CODE_USER2                 ((uint32_t) 0xF002u)

ZX_EXCP_USER_CODE_PROCESS_NAME_CHANGED 代碼將供 Starnix 和 適用於上述用途的偵錯工具ZX_EXCP_USER_CODE_USER0 ZX_EXCP_USER_CODE_USER1 和 ZX_EXCP_USER_CODE_USER2 代碼是針對 特定應用程式的使用方式，與 PA_USER0、PA_USER1 和 PA_USER2 類似。

小於 ZX_EXCP_USER_CODE_USER0 的代碼將保留給整個系統； 可在後續的 RFC 中定義

引發使用者定義的例外狀況

這個 RFC 定義了用來提高使用者定義例外狀況的 syscall：

zx_status_t zx_thread_raise_exception(uint32_t options,
                                      zx_excp_type_t type,
                                      const zx_exception_context_t* context);

這個 syscall 會在目前的執行緒上引發 type 類型的例外狀況，其中包含 指定的例外狀況內容。

目前，options 引數必須是 ZX_EXCEPTION_JOB_DEBUGGER， 其值為 1。如果呼叫端傳遞任何其他值，則系統呼叫 會傳回 ZX_ERR_INVALID_ARGS。如果提供這個值，例外狀況就會 將傳送至工作偵錯工具管道 (如有)。

type 引數必須為 ZX_EXCP_USER。如果來電者 值，syscall 會傳回 ZX_ERR_INVALID_ARGS。

系統會忽略 context 的 arch 欄位。《synth_code》和《synth_data》 context 中的欄位目前是主要用來傳達 資訊

如果您希望將此系統呼叫延伸到其他型別 則可在之後的 RFC 中擴充 syscall 的語意。

實作

我們將透過新增設計中所述的 syscall 來實作此功能 專區。所有用來提高例外狀況的機械都已存在 Zircon。第二個 CL 將訓練 debug_agent 監聽這些例外狀況 再重新檢查產生例外狀況的程序名稱。

概念驗證 CL 展示了在 Zircon 和 debug_agent 很簡單。

成效

這項設計對系統效能的影響微乎其微。就在同一個例子中 如果沒有任何執行中的 debug_agent，zx_thread_raise_exception 會 並留意到指令 沒有人在監聽偵錯工具例外狀況管道。

反之，如果系統中有許多 debug_agent 執行個體正在執行， 這個機制能有效率地將通知傳送給他們

這個程式碼路徑已針對這兩種情況進行最佳化，因為 機制是用來通知 debug_agent 其他常見事件，例如 正在啟動程序

人體工學

此 RFC 中說明的方法並非特別符合人體工學。例如： Starnix 必須記住每次發生時都要引發適當的例外狀況 變更程序名稱Zircon 是符合人體工學的設計 會在程序名稱變更時自動引發此例外狀況。不過 這種做法相當困難，因為程序名稱可以從任何 系統中處理執行緒的執行緒。Zircon 沒有 機制，從遠端執行緒引發例外狀況，並新增這類 機制會導致 Zircon 變得複雜 (例如檢查 待處理例外狀況)。

回溯相容性

本文件所述的設計可回溯相容於現有 有些人會將 Cloud Storage 視為檔案系統 但實際上不是zx_thread_raise_exception 可產生的例外狀況如下： 清楚標示為使用者產生的例外狀況，並利用 核心產生的例外狀況。這項設計也會保留命名空間，供日後使用 使用者和核心產生的例外狀況

安全性考量

zx_thread_raise_exception 可讓使用者空間產生 但無法產生先前無法產生的例外狀況，因此攻擊者可以使用 操控監聽例外狀況的軟體。這項提案 限制使用者產生的例外狀況，使其保有 ZX_EXCP_SYNTH 位元設定，並設定為這些例外狀況的保留命名空間。

使用者空間可能已在微架構層級產生一些例外狀況 例如使用 ARM 和 Intel 上的 brk 和 int3 指令， 這意味著，新增核心協調機制 也會減少產生例外的情況

隱私權注意事項

雖然程序名稱可能含有隱私機密資訊 不過，這個新機制仍無法存取相關資訊， 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作舉例來說，這類設計在隱私權屬性方面比 新程序名稱與例外狀況的設計

測試

新的系統呼叫將由 Zircon 核心測試來測試。

偵錯工具整合功能會透過整合測試進行測試。

說明文件

新系統呼叫將與 syscall 手冊頁面一樣， Zircon 系統呼叫。新的例外狀況語意也會記錄在 例外狀況處理概念頁面。

缺點、替代方案和未知

我們考慮過多種替代方案：

使用微架構例外狀況

與其新增 syscall 來引發例外狀況，我們可以使用現有的 用於提高例外狀況的微架構機制 (例如 brk 和 int3) 指示)。這個方法的缺點是，這些例外狀況嚴重到 除非已處理我們可以訓練 crashsvc 辨識這些例外狀況， 但由於我們不願意讓 crashsvc 瞭解 與 crashsvc 無關的系統功能。

程序名稱變更時自動產生例外狀況

之後不要要求 Starnix 呼叫 zx_thread_raise_exception 變更程序名稱後，我們可以透過 Zircon 產生例外狀況 會自動套用變更。不過如先前所述 上述的 Zircon 程序名稱可以透過 Zircon 沒有產生例外狀況的機制 遠端執行緒上的事件

幸運的是，Starnix 只會實際變更 是指名稱改變的程式 因此您不必解決 例外狀況，以便處理手邊用途