RTL Anti-Tampering Design 第十四課：RTL 與 netlist 故障攻擊活動

一份故障測試活動（fault campaign）需要可重播的實驗規格。只報隨機翻位後的百分比，讀者無法核對測試範圍。它必須記錄設計版本、注入目標、時點、效果、預算、判準與無法模擬之處。

學習目標與課堂安排

完成本課後，你應能：

區分 attempts、events 與 unique covered bins。
推導單事件／雙事件空間及零觀察機率上界。
重播第一個違規 commit，說明 RTL/netlist 目標映射缺口。

建議 50 分鐘的教師安排：事件定義 10 分鐘、fixture 計數 10 分鐘、空間與統計推導 15 分鐘、時序和網表映射討論 15 分鐘。時間含學生手算、互動與討論；這是教學規劃，尚未做學生課堂時間量測。

第十四課：RTL 與 netlist 故障攻擊活動

先固定一次嘗試的意義

消防演習若每次都換出口、煙霧位置與集合時間，兩次演習的通過率無法比較。硬體 fault campaign 也要固定版本、seed、一次 attempt 包含幾個事件，以及失敗/重試是否另算。生活類比不能保證 fault injection 工具真的達到晶片節點。

在 RTL 模型先列出目標清單與時間窗，再定義效果（flip、stuck-at、skip、延遲）及每次注入預算；將 fault-free controls、合法操作、未授權操作及拒絕服務分開。每條反例保留完整輸入序列、第一個錯誤 commit、隨機 seed 與模型 hash。SYNFI 示範 synthesized netlist 預先故障分析；netlist 結果仍不等於實體注入。SYNFI。

注入目標的映射（mapped target）記錄 RTL 訊號如何對應到 netlist cell。兩者可能不同：綜合可能合併 redundant logic、重編碼 FSM、複製/移除暫存器。兩階段 campaign 要保留 RTL signal 到 netlist cell 的 mapping 與 unmapped 清單。結果至少分類為安全性違反、可用性故障、偵測且及時阻擋、偵測太晚、未觸發、工具不可觀察；不能把「detected」一律當成功。

固定設計 hash 和故障預算後，先跑未故障對照，再跑單故障與明確界定的組合故障。以下 property 草案尚未編譯；assert 要查每個接受事件的 oracle，不只查 alert。Coverage 必須列出未觸及 target/time bin，不以總 fault 數掩蓋空白。

本課互動範例用四種目標類別（ROM check_done、debug permission、first fetch、key release）乘上三個合成時間窗形成 12 個 target/time pairs。邊緣位置描述注入位置，不能代替目標類別；這是固定的教學分母，不是硬體 coverage。

保留可重播證據

每筆結果需要 attempt ID、DUT/網表 hash、工具版本、配置、seed、target、effect、edge/window、budget、輸入 trace、輸出、assertions、分類與重播命令。若工具以最佳化跳過未改變輸出之案例，須說明 pruning 規則及其等價性假設。

實作案例：四次嘗試，究竟覆蓋了多少？

開啟本課互動實驗

第十二課留下兩個接受端：first fetch 與 key release；第十一課還有 ROM check_done 和 debug permission。現在把這四種目標類別各配三個合成時間窗，得到 4 × 3 = 12 個 target/time pairs。A–D 邊緣只描述注入位置，不是另外四種目標類別。分母先寫出來，才能知道四次嘗試是四個新位置，還是反覆打同一個 bin。

本課使用固定的十二筆教學 fixture。模式選合成 campaign（Campaign fixture），將 attempts 滑桿設為 4、budget 設為 2，再逐筆追蹤下表。原頁面 attempts 預設為 6，須先改成 4 才會得到本文結果。這裡的 attempt 是一次完整嘗試；events 是該次施加的故障事件數。嘗試二需要兩個事件，所以不能把「每次兩事件」錯看成「最多跑兩次」。這份結果沒有執行 RTL simulator 或實體注入。

Attempt	target/time	所需 events	在 budget 2 下	分類
try-001	ROM/t1	1	已觸發、可觀察	未授權 commit，且 alert 太晚
try-002	ROM/t1	2	已觸發、可觀察	及時阻擋
try-003	debug/t3	1	已觸發、可觀察	可用性故障
try-004	ROM/t1	1	trigger 不成立	未觸發

四筆 attempt 共選到兩個唯一 bins：ROM/t1 與 debug/t3；可觀察且已觸發的 bins 也為兩個。因此這個教學分母下的觸及範圍是 2/12，另有 10 個沒有觸及，不能寫成 4/12。施加事件總數是 1 + 2 + 1 + 0 = 4。try-004 雖列在嘗試清單，沒有真正施加事件，不能算成一筆通過的故障測試。

分類會重疊，時間順序不能省略

try-001 的第一個未授權 commit 在教學 edge 4，之後才有 alert。這一筆同時屬於安全性違反與遲到警示。兩個計數不是兩次不同嘗試，所以把分類列相加，可能比已觸發嘗試數更多。報告應保留每個 attempt 的多個結果欄位，不能為了讓百分比加總為 100% 而抹去時間關係。

try-002 是故障已施加而及時阻擋的例子。它可以說明保護在這筆模型刺激下有作用，卻不是無故障正向控制。真正的 fault-free control 位於另一個模式，記為 ctl-001：獨立 oracle 授權合法操作，教學 commitEdge 為 3，assertion 為 PASS、cover 命中。這一筆控制案例另計，不加入十二筆注入 fixture 的分母；此處的 PASS 也只是模型欄位，不是工具跑出的 formal proof。

try-003 延遲了服務而沒有錯誤 commit，是可用性問題。不能把「沒有未授權 commit」一律算成可部署；安全性與能否服務合法請求須分開。try-004 則根本未觸發，既不能證明阻擋，也不能證明攻擊有效。這兩筆需要的後續工作不同：前者分析恢復與逾時，後者先確認故障刺激與目標時窗。

只改 budget，結果為什麼會變？

把每次 budget 從 2 改成 1，保留同樣的前四筆。try-002 需要兩個事件，所以現在不啟動；try-001、try-003 各施加一個事件，try-004 仍未觸發。總事件數變成 2，未啟動的嘗試有 2 筆，及時阻擋計數變成 0。這不是設計突然退步，而是本次實驗沒有執行原先那個兩事件阻擋案例。

選取的唯一 bins 仍是兩個，可觀察且已觸發的 bins 也仍是兩個，因為 ROM/t1 還有 try-001，debug/t3 還有 try-003。這說明一個 coverage 數字可能完全不變，而實際刺激集合已改變。比較 campaign 時，必須一起比較版本、fixture、事件預算與逐筆結果，不只比最上方的百分比。

若選合成 campaign 但把 attempts 設為 0，只是選了 fixture，campaign 尚未執行。另一種缺口是工具不可觀察：例如 fixture 中 try-005 有故障事件，卻沒有工具可見的結果；不能把缺少觀察算作成功阻擋。這些狀態需要保留原名與原因，讓重播者辨認是刺激缺失、觀察缺失，還是確實得到結果。

延伸練習：寫出可重播而不誇大的摘要

練習 A：重算分母。 模式選 Campaign fixture，attempts 設 4、budget 設 2，列 attempts、施加 events、選取 bins、可觀察已觸發 bins、未觸及 bins，再解釋為何四筆不等於四個 bins。

解答與推導： 分別為 4、4、2、2、10。try-001、try-002、try-004 都在 ROM/t1；try-003 在 debug/t3。重複嘗試可用來研究穩定性或不同 effect，但不會新增 target/time bin。這個十二格分母也不涵蓋所有 lifecycle、reset、effect 組合，不能稱為完整產品 coverage。

練習 B：找出錯誤結論。 摘要寫「try-001 有 alert，所以防護成功；try-004 沒有錯誤，所以通過」。請各寫一句更正。

解答與推導： try-001 在 edge 4 已未授權 commit，alert 太晚，不能算及時阻擋。try-004 的 trigger 不成立，因此未執行有效故障嘗試，結果不是 PASS。兩句都需保留原 trace，不用最終 alert 或最終資料狀態代替首次錯誤事件。

練習 C：交給另一位工程師。 同事收到 try-002 的結果表，卻沒有 fixture 版本與 budget。為什麼即使 target/time 相同，也可能重播出不同結果？

解答與推導： 同一 bin 可以放不同事件序列；try-002 特別需要兩個事件。若同事用 budget 1，它就不啟動。應提供固定 fixture、版本或 hash、模式、attempt 範圍、事件預算及分類規則；實際 RTL/netlist campaign 還要補 DUT、工具、seed 與輸入 trace。教學介面的手算不能取代那些工具證據。

課堂推導：故障空間、抽樣與第一次錯誤事件

先將 commit 定義為接受端讓操作產生不可逆副作用的事件，例如第一筆未授權取指或金鑰使用。Mapped target 指 RTL 訊號與綜合後網表節點的對應。沒有這兩個定義，讀者容易把「看到 alert」與「資產尚未被使用」混在一起，也不知道兩階段 campaign 是否真的在評估同一個目標。

假設一個新增教學空間有 1000 個單位元注入位置、500 個候選時鐘邊緣，每次一個 bit flip。單事件位置／時間組合共有 N = 1000×500 = 500,000 個。若允許兩個不同的單事件組合且不計順序，數量為 C(N,2)=N(N−1)/2=124,999,750,000，約 1.25×10¹¹。這裡計的是單位元位置，不是忽略暫存器位寬的「1000 個暫存器」。

這個計數還沒有加入 fault effect、持續時間、lifecycle、reset 或重複打同一位置。若兩事件的先後順序也屬規格，或同一事件可以重複，分母又會不同。定義清楚後，才可討論影響錐縮減、分層抽樣或形式化分析。Pruning 若宣稱兩個目標等價，需要保留依據；被刪去的項目也應可追溯，而不能直接變成已覆蓋。

零次違規能給什麼統計上界？

另設一個抽樣模型：每次獨立依同一固定分布抽取故障案例，並由可信 oracle 判斷是否違規。令 p 為該抽樣分布下的違規機率，n 次都未觀察到違規的機率為 (1−p)ⁿ。取單側 95% 上界時，解 (1−p_upper)^n = 0.05，得到 p_upper = 1−0.05^(1/n)。n = 3000 時約 0.000998，換成百分比約 0.0998%；常見近似 3/n 則為 0.1%。

推導中的 p 有明確分布與判定方法，不是每個故障點都安全的機率。若只重複同一筆固定 fixture、樣本相依、oracle 看不到副作用，或實體注入未到達指定節點，就不符合這份推導。特別挑選的稀有目標也可能被原抽樣分布極低估。均勻抽樣可以是一個明定的分布，卻不是所有產品評估都必須採用的假設。

時間線必須忠於資料列

現有 try-001 只固定 firstBadCommitEdge = 4 以及 lateAlert = true；它沒有提供數值型的注入邊緣或 alert 邊緣。A-edge 是位置名稱。可據此確定「commit 在 edge 4，alert 之後才到」，不能替它補成「edge 3 注入、edge 5 警示」並稱為原始 trace。

為練習窗口檢查，另外造一條三事件教學 trace：edge 2 施加 skip、edge 4 未授權 commit、edge 5 alert。這是新手算例。若及時阻擋契約要求 blockEdge < firstBadCommitEdge，edge 5 的告警顯然不滿足；同拍阻擋是否有效也要看實際取樣與副作用順序。真實報告應保留足以判斷該順序的波形或事件日誌。

RTL 到 netlist 也需重新定義位置。例如教學 FSM 的二位元狀態表示經綜合改成四個 one-hot 暫存器，原本翻動 state[1] 不會自動等於翻動某一個網表 flop。要記錄編碼、對應及非法狀態行為，並在新層級重跑指定刺激。這是可能的重新編碼例，不是宣稱某次綜合工具必然如此處理。

計算練習： 在上述獨立抽樣假設下，30 次零違規的單側 95% 上界是多少？能否用這個數字，把現有十二格 fixture 的未觸及十格標成安全？

完整解答： 1−0.05^(1/30) ≈ 0.095034，即 9.5034%；3/30 近似為 10%。不能把未觸及 bins 改為安全：統計參數屬於指定抽樣分布，未觸及項仍缺逐格證據，而且固定 fixture 根本沒有提供這三十次獨立抽樣。下載程式把計數與統計假設分開輸出。

重算與核對

下載程式與結果 JSON 到同一資料夾，以 Python 3.8 以上執行：

python rtl-university-workbook-v1.py --output replay.json

比對 replay.json 與提供的結果檔，先核對本課的 lesson14 欄位。sourceSha256 記錄程式檔案的位元組身分，與算例正確性分開檢查；若編輯內容或把 LF 另存成 CRLF，這個值也會改變。保留原下載檔再做練習，並將學生改版另存，才能分辨方法改變與檔案改變。

下載課堂重算程式 · 查看固定結果 JSON

離線互動實驗

RTL／SVA 審查方向

以下為性質草案：先定義 harness 的 transaction、reset 與 oracle，並確認取樣邊界，再接入設計；尚未編譯或證明。reference_authorized 必須來自獨立的參考模型，且不在故障注入目標或影響錐內。若 DUT 內的 permission bit 本身也可能受故障影響，就不能拿它當 oracle。

assert property (@(posedge clk) disable iff (!rst_n)
accepted_commit |-> reference_authorized);

若 accepted_commit 從未成立，property 仍可能 vacuous pass。另以 cover 確認無故障且授權的流程確實接受；disable iff 排除的 reset 期間、未觸發的 attempt 與遲到警示要分開分類。此片段不證明 CDC、timing、side-channel 或實體注入；需由各自工具與測量提供證據。

檢核問題

辨認：fault attempt 與 fault outcome 有何不同？ 推理： Attempt 記錄刺激與目標；Outcome 記錄觀察到的效應、接受狀態、detector 回應，以及接受是否早於 alert。
比較：為什麼總 attempts 不能當成 coverage 分母？ 推理： 多次嘗試可能落在同一個 target/time bin。要列完整 bin 集合、實際觸及的唯一 bins，以及未觸及 bins。
情境：未授權 commit 之後才出現 alert，campaign 要如何分類？ 推理： 同時記錄未授權 commit 與延遲 alert。不能把 alert 算成及時阻擋；結果類別可能重疊。
故障診斷：模擬器刪去輸出沒有改變的案例，必須補記什麼？ 推理： 記錄刪減規則與等價性假設，並保留代表性已刪除／保留案例的重播方法。
設計風險／轉移：下個月要讓另一位工程師重現一個 counterexample，需保留哪些欄位？ 推理： 保留 source/netlist 與工具 hash、設定、seed、目標／時間窗、budget、輸入 trace、輸出、assertion、分類規則及 replay command。

延伸閱讀

SYNFI pre-silicon fault analysis

MY ACADEMY · LESSON FILM

教學影片

影片依序說明本課的資料路徑。看完一段，可以回到下面的互動練習，改變輸入或故障條件。動畫呈現教學模型；它沒有替代 RTL 模擬。

圖卡的範圍說明
教學模型 · 非 RTL 模擬或晶片實測
框線動畫只是閱讀順序；不是已執行的 fault campaign 或命中率

下載 MP4 · 字幕 VTT

旁白使用合成聲音。互動教學與動畫均有模型邊界；請以本課的來源與驗證範圍解讀結果。

Wrap-up｜把這一課帶回設計審查

威脅模型與成立條件: 固定 RTL/netlist hash、fault target/effect/time/budget，資產為接受端不受未授權提交。
失效原因: 模糊 attempt、target mapping 或把 detected 當 pass，會令 campaign 不可比較或漏掉違規。
防護方法: 用 fault-free 控制與分級結果建立可重播活動，分開 safety、availability、timely block 與 tool gaps。
驗證方式與待做檢查: 保存 seed/工具配置/hash/trace/first bad commit，RTL和netlist兩套分母及 unmapped targets分開。
防護界線與未驗證項目: 工具模型與數位 netlist 不代表實體擾動可達性、頻率、位置精度或故障相關性。

換個情境再想一次

挑一個未映射 RTL target，提出對應 netlist cell 的確認方法及無法映射時的報告語句。

以上整理對照本課的教學案例、參考資料與實驗範圍；未列為已完成的驗證，都是後續工作。