跳轉到

2.3 位元碼驗證與 Class Loader#

問題：如何信任一段外來位元碼？#

JVM 的安全性承諾建立在兩個前提上：位元碼不能偽造型別系統（例如把整數當指標用），且不能繞過存取控制（例如存取 private 欄位）。但 .class 檔只是位元組串流，可能來自網路、可能被竄改、也可能出自惡意的自製編譯器——Java 語言編譯器會產生合法位元碼，但 JVM 不能假設所有位元碼都來自合法編譯器。因此 JVM 必須在載入時靜態驗證每一段位元碼，證明它們不會使 VM 進入未定義狀態。這就是位元碼驗證器（bytecode verifier）的角色，也是程序虛擬機相較於組合語言最本質的差異：x86 的機器碼無法被靜態驗證（判斷一段機器碼是否只做安全操作等價於停機問題），但 JVM 位元碼被刻意設計成「可驗證」的形式——指令操作數型別在每個程式點都可被推導。

驗證的理論：型別推導與資料流分析#

驗證器的核心是對位元碼做抽象直譯（abstract interpretation）：不執行程式，而是以型別為值域做資料流分析。對每個方法，驗證器模擬每條指令對「運算堆疊與區域變數的型別狀態」的影響：

typestate = (stack: [Type...], locals: Type[...])

worklist := {(入口, typestate0)}
while worklist 非空:
  (pc, ts) := worklist.pop()
  instr := code[pc]
  ts' := transfer(instr, ts)   // 依指令語義推導新 typestate
  if ts' 型別不匹配（如 pop 一個 int 當 reference 用）:
    reject  // VerifyError
  if (pc 的後繼, ts') 尚未以相同或更精確狀態記錄過:
    worklist.push(...)
若所有路徑皆通過 -> accept

關鍵的設計約束是：在每個 jump 目標處，無論從哪條路徑抵達，typestate 必須一致（JVM 規格明文要求）。這個約束讓驗證不需要做路徑敏感分析，只需對每個程式點收斂出一個型別狀態。型別合併採用型別格（type lattice）的最小上界：例如兩條路徑分別推得 String 與 Object，合併為 Object。含分支的推導本質上是個不動點計算，理論基礎來自 1977 年 Cousot 夫婦的抽象直譯理論；把這套理論落實到 JVM 驗證的關鍵工作包括 1998 年前後 Yellin 的規格化以及 Raymie Stata 與 Qian 等人的形式化（Qian 在 1998-2000 年證明了（修正後的）驗證演算法的健全性）。

歷史上有兩代驗證器：JVM 1.0 的推導式驗證器（inferencing verifier）需要對每個指令做型別方程求解，實作複雜且曾出現多個漏洞；Java 6（2006）起採用 StackMapTable——編譯器在 class 檔中預先寫入每個分支目標的型別狀態，驗證器只需線性掃描核對，演算法簡單、單遍完成。這是「把驗證負擔從 VM 移到編譯器」的典範轉移，也大幅簡化了 mobile 裝置上的驗證實作（早期 Java Card 與 CLDC 更是採用離線預驗證）。

類別載入子系統：連結的三階段#

驗證只是連結（linking）過程的一環。JVM 的類別生命週期為：載入（loading）→ 驗證（verification）→ 準備（preparation，配置靜態欄位並設預設值）→ 解析（resolution，把常數池的符號引用轉為直接引用，可延遲）→ 初始化（initialization，執行 <clinit>）。Class Loader 子系統的核心設計是委派模型（delegation model）：

Bootstrap Loader（核心 API，如 java.lang）
   ↑ 委派
Extension/Platform Loader
   ↑ 委派
Application Loader（classpath）
   ↑ 委派
自訂 Loader（如網路、加密 class 檔）

當一個 loader 收到載入請求，先委派給父 loader；只有父 loader 無法載入時才自己載入。這個 1997 年前後定型的模型有兩個目的：一致性（核心類別如 java.lang.String 永遠由 bootstrap 載入，任何自訂 loader 都無法偽造核心類別——這堵住了以假 java.lang.String 覆蓋安全檢查的攻擊）與唯一性（同一 class 檔由同一 loader 載入兩次的兩個類別被視為不同類別，避免型別混亂）。委派模型的反面是刻意保留的彈性：servlet 容器與 OSGi 利用「兄弟 loader、各自可見」實現應用隔離與熱部署——同一個類別可以被多個 loader 各載入一份，這成為 Java 世界中「程序內多重空間」的基礎。

動態載入還帶來了惰性解析的效能設計：invokevirtual 引用的方法在第一次執行前才解析；配合 4.2 節的內嵌快取，JVM 能在類別隨時可被改動的動態環境中仍然高效。這與 C 編譯器「連結期固定一切」的靜態模型形成鮮明對照——虛擬機把連結從建置期搬到了執行期，代價是 VM 必須自己維護符號表與動態連結器（功能上對應了作業系統的動態連結器 ld.so，但作用在類別與方法粒度）。

安全模型與歷史漏洞#

位元碼驗證 + 類別載入委派 +（舊制的）SecurityManager 檢查構成 Java applet 時代的沙箱三支柱。歷史上的著名事故包括：1990 年代末的類型混淆攻擊（以兩個 loader 各載入同名類別，誘使 VM 把 A 型別物件當 B 型別用，進而偽造指標——修補方式是在快速型別檢查時一併核對 loader 身分）、以及 2012-2013 年間多起驗證器繞過漏洞（攻擊者直接手工構造違規位元碼，被舊版驗證器的 bug 漏掉），這些事件促使瀏覽器廠商最終淘汰 applet，也說明了「驗證器是 TCB，其正確性必須以形式化方法對待」——學界如 Jinja/JVM 形式化模型與 CompCert 式的機器檢查驗證器正是回應此需求。

小結#

位元碼驗證是程序虛擬機的「型別安全合約」：以抽象直譯與不動點計算，在載入期靜態證明位元碼不會破壞 VM 不變量；Class Loader 則以層級委派確保命名空間與核心類別完整性。兩者合起來，讓「執行不可信程式碼」從冒險變成工程常態，也定義了 .NET CLR、Android ART 與 WebAssembly 驗證器共同遵循的設計範式。