標籤: ARM

[Tempest Agent 深度解讀] Nvidia 為失控 AI 代理打造「外部斷路器」：安全邊界為何必須移出模型 (2026-09-30)

事件背景：這不是一顆萬能的「關機鈕」

Nvidia 發表 Open Agent Safety Platform，試圖解決一個逐漸迫切的問題：當 AI 代理不只回答問題，而能讀寫檔案、使用憑證、呼叫 API、執行程式甚至操作其他系統時，靠提示詞告訴它「不要越界」，已不能視為可靠的安全控制。

已確認的來源事實是：平台由開源執行環境 OpenShell 與 Sentry 參考設計構成。OpenShell 在軟體層隔離代理；Sentry 則於 BlueField-4 DPU 上充當獨立監控者。Nvidia 宣稱，一旦代理跨越預設邊界，系統可在毫秒尺度將其隔離。原始報導見 https://gulfnews.com/technology/nvidia-builds-hardware-kill-switch-to-stop-ai-agents-that-go-rogue-1.500692624。

因此，「硬體斷路器」是便於理解的說法，卻容易造成誤解。它不是能關閉所有 AI 的實體開關，也無法判斷任何行為在倫理上是否正確；它真正做的是在既定政策遭違反時，從代理碰不到的外部位置切斷或隔離其活動。

運作機制：把信任邊界移出模型

OpenShell 採預設拒絕：代理被放進獨立沙箱，沒有任意網路存取權，也不能自由讀寫主機檔案。操作者透過政策指定可接觸的路徑、程序、網站、API 與憑證。Nvidia 的開源專案說明顯示，檔案存取、系統呼叫與網路連線會受到核心層控制；真正的憑證不直接交給代理，而是在請求前往核准端點時才注入。政策變更也可先接受形式驗證與人工審查。技術細節可見 https://github.com/NVIDIA/OpenShell。

Sentry 再增加一層「頻外」監控。在 Nvidia 描述的 Vera Rubin POD 架構中，BlueField-4 位於節點通往模型的必經路徑，可把代理互動、政策判定以及工具與資料存取串成活動紀錄，並執行即時政策。由於監控邏輯與代理所在的主機分離，即使代理取得較高主機權限，也較難直接關掉看守者。第一方架構說明見 https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/。

商業邏輯：開放軟體，拉高基礎設施價值

合理推論是：Nvidia 正把競爭位置從 GPU 運算延伸至代理的安全控制面。OpenShell 採 Apache 2.0 授權，並可延伸至 Arm、Intel 等平台，有利於先讓政策格式與執行模式形成生態系；需要更強隔離的資料中心，則可選用結合 BlueField-4 的 Sentry。這是一種典型的平台策略：軟體降低採用門檻，硬體承接高保障、高規模部署的價值。

現在值得注意，是因為代理獲得的權限與執行時間正在增加。一般聊天機器人答錯，影響多半停留在內容；能操作程式碼、付款流程、企業資料或生產設備的代理一旦偏航，錯誤會轉化成真實系統狀態。安全問題因而從「模型會說什麼」，轉向「模型實際被允許做什麼」。

實際影響與容易忽略的限制

對企業而言，最直接的價值不是消滅幻覺，而是縮小事故半徑：限制資料外傳目的地、避免憑證被任意挪用、留下允許與拒絕紀錄，並在越界時快速隔離。這些紀錄有助於鑑識與追查責任，但證據保存、復原與重新上線仍須搭配既有的事件應變流程。

限制同樣明確。第一，系統只能執行人類寫下的邊界；若錯誤操作本來就在允許範圍內，斷路器未必會啟動。第二，政策太緊會讓代理失去效用，太鬆又失去保護。美聯社訪問的威斯康辛大學教授 Somesh Jha 也指出，安全與可用性的平衡仍需透過案例驗證；報導並強調，此平台不能自動阻止模型欺騙、犯錯或產生不實內容：https://apnews.com/article/nvidia-ai-security-openshell-sentry-a4cfc84ed00353ff8f2dad4bed7b429e。

第三，「毫秒隔離」目前主要是廠商主張，尚不能取代不同負載、繞路情境與故障模式下的獨立測試。Sentry 也是可選的硬體層，而非所有安裝 OpenShell 的系統都天然具備同等保障。若代理仍能透過未納管的主機、外部工具或人工帳號行動，安全邊界就可能出現缺口。

對台灣讀者的意義

作者觀點是：台灣真正需要關注的，不是「AI 是否有自我意識」，而是代理權限如何落實到伺服器、網路與憑證架構。對金融、製造、醫療及政府機關而言，採購 AI 代理時應一併要求最小授權、端點綁定憑證、不可竄改稽核紀錄與緊急隔離機制，而不是只驗收模型準確率。

對伺服器、網通與資安供應鏈，這也意味產品設計將新增一層需求：代理沙箱、DPU 頻外監控、政策驗證及跨系統事件紀錄，可能逐漸成為企業 AI 基礎設施的標準配備。機會不只在晶片製造，也在韌體整合、資安代管、政策工具與驗證服務。

後續觀察指標

  • 是否出現可重現的第三方測試，驗證隔離延遲、繞過方式與誤判率。
  • OpenShell 能否在非 Nvidia 平台維持相近的控制完整性。
  • 企業是否真正部署 Sentry，而非僅表態支持或試用開源軟體。
  • 政策撰寫與審批能否跟上大量代理、子代理及動態工具的規模。
  • 事故後能否完整還原代理使用的身分、憑證、工具與資料路徑。

這項發布的核心意義，不在於 Nvidia 已經「解決失控 AI」，而是把安全責任從模型的自我約束，重新放回可驗證、可稽核、可強制執行的基礎設施。方向合理，成效仍要由真實部署與獨立測試證明。

[Tempest Rust 深度解讀] 一個乘加運算，挖出 Rust 與 musl 的浮點數陷阱 (2026-09-03)

一個看似單純的 a × b + c，揭露了 Rust 標準函式庫與 musl libc 在極端浮點數輸入下可能算錯一個最低有效位元。問題不在 FMA 硬體指令本身，而在沒有對應硬體時啟用的軟體模擬路徑。這起事件真正值得注意之處，是同一段帶有歷史來源的實作，如何跨越 C 與 Rust 生態，讓罕見錯誤在多年後才被模擬器與反例測試照亮。

FMA 為何不是普通的乘法再加法

來源事實：FMA（融合乘加）先以完整精度計算乘積與加總，最後只捨入一次；若分開執行乘法和加法，乘積會先捨入，加總後再捨入一次。Rust 官方文件因此明確承諾，f32::mul_add 的結果應等同「無限精度計算後再捨入」，而且通常比非融合運算準確。文件也提醒，只有目標架構具備專用指令時，FMA 才不一定付出額外效能成本。來源：https://doc.rust-lang.org/std/primitive.f32.html#method.mul_add

FMA 是多項式求值、三角函數、向量運算與誤差補償演算法的重要積木。它的價值不只是「多一點精度」，而是讓上層演算法能把誤差限制建立在一次捨入的契約上。若底層偷偷多捨入一次，最終數值可能只差一個 ULP（相鄰可表示浮點數之間的距離），但原先證明的誤差界線已經失效。

從向量化最佳化一路追到標準函式庫

來源事實：Sergey Davidoff 原本想替 fearless_simd 實作沒有硬體 FMA 時仍可向量化的替代方案。他依據 Boldo 與 Melquiond 的演算法，把 f32 輸入提升為 f64 計算，再處理恰落於捨入中點的情形。該研究以「rounding to odd」避免雙重捨入，並使用 Coq 對演算法作形式化證明。論文資料可見：https://toccata.gitlabpages.inria.fr/toccata/publications/boldo_bib.html

然而，形式證明保證的是演算法，不是人工轉譯出的程式碼。外部貢獻者提出反例後，Davidoff 發現自己的版本漏掉次正規數（subnormal）處理。這類數值位於零與最小正規浮點數之間，表示方式與一般浮點數不同，常見的位元判斷技巧不能直接套用。修正並增加大量針對性隨機測試後，測試仍只在模擬舊指令集時失敗，最後反而定位到 Rust 的 f32::mul_add 與 std::simd 軟體後備路徑。完整調查原文：https://shnatsel.github.io/implementing-fma-finding-bugs-in-std/

真正的漏洞是「雙重捨入」

軟體模擬通常利用較高精度格式承接中間結果，例如先在 f64 中算出 f32 × f32 + f32，再轉回 f32。絕大多數輸入如此即可得到正確答案；危險發生在高精度結果先被捨入到一個精巧的中點，第二次轉型又依「最接近、平手取偶數」規則選錯方向。原有判斷式能攔截一般中點，卻忽略次正規區間，因此錯誤只在極少數位元組合出現。

來源事實：Rust 程式碼註記顯示這條路徑源自 musl 的 fmaf()，而 musl 又標示源自 FreeBSD。musl 郵件論壇的交叉驗證不只承認次正規數雙重捨入問題，也提出修補與重寫版本；2026 年 8 月 16 日的討論列出具體錯誤案例、低於正常範圍時漏設 underflow 狀態旗標，以及不同架構下的程式碼大小。來源：https://www.openwall.com/lists/musl/2026/08/16/2

合理推論：這不是 Rust「記憶體安全失守」，也不是所有 FMA 都算錯，而是標準函式庫重用既有數值程式碼時，連同其中未被測出的邊界假設一起繼承。複用成熟程式碼能降低開發成本，卻也可能形成跨專案的共同失效模式；程式越老、移植範圍越廣，單靠來源聲譽越不足以取代回歸測試。

實際風險：小誤差不等於零風險

來源事實：原始反例的結果只差最低有效位元，作者估計約偏離正確結果 15 ppm。他也明白表示，尚不知道這個錯誤在真實工作負載中的影響。硬體直接提供 FMA 的系統不走這條後備路徑；依其測試範圍，64 位元 Arm 不受影響，風險主要落在缺乏 FMA 的舊款或低階 x86、32 位元 Arm及部分嵌入式環境。

合理推論：一般介面動畫、影像效果或可容忍近似值的計算，單次一個 ULP 的差異通常不會造成可見故障。更值得戒備的是要求跨機器位元一致的模擬、以嚴格誤差界線驗證的科學程式，以及會反覆放大或依臨界值分支的數值流程。同一份程式在具備硬體 FMA 的開發機正常，部署到舊處理器後才走錯誤路徑，會讓問題特別難重現。

容易忽略的兩個限制

第一，不能由這個反例推導出所有金融、科學或控制系統都會產生重大偏差；是否擴大，取決於上層演算法、輸入分布與迭代方式。第二，正確數值還不等於完整符合 C 的浮點環境語意。musl 討論同時處理 inexact、underflow 等狀態旗標，Davidoff 也指出自己的 Rust 修補曾在某些案例破壞旗標行為。結果位元正確與例外狀態正確，是兩組都必須測試的契約。

對台灣開發團隊的意義

作者觀點：台灣讀者最該帶走的不是「Rust 或 musl 不可靠」，而是硬體分流本身就是測試維度。投入 IoT、工控設備、長生命週期產品或跨架構軟體的團隊，不能只在當代 x86-64 與 Arm64 主機跑 CI；若產品仍支援 32 位元 Arm、軟浮點或精簡指令集，應以模擬器或實機強制覆蓋軟體後備路徑。供應鏈盤點也應追到 libc、編譯器版本與目標 CPU 特徵，而不只是應用程式套件版本。

後續觀察指標

  • Rust 標準函式庫修補是否完成審查，並同時通過結果位元與浮點例外旗標測試。
  • musl 的 fmaf() 修補或重寫何時進入正式版本，以及舊版發行分支是否回補。
  • FreeBSD 衍生實作及其他嵌入式工具鏈是否含有相同中點判斷。
  • 專案 CI 是否真的執行無硬體 FMA、次正規輸入與不同捨入模式，而非只測主流開發機。

最直接的健康檢查，是使用原文提供的位元反例：a=0x97000800、b=0x1cfff001、c=0x00010002。正確 fmaf(a,b,c) 結果應為 0x00010001；若得到 0x00010002，便命中了這條錯誤路徑。這個小測試無法取代完整驗證，卻足以提醒團隊：最罕見的數值邊界，往往正藏在最少被執行的相容性程式碼裡。