Tag: cache

上次寫了 Meltdown 攻擊的讀書心得 (參考「讀書時間：Meltdown 的攻擊方式」)，結果後來中獎狂流鼻水，加上 Spectre 用的手法就更複雜，慢慢看的情況就拖到最近才看完... 這邊就以讀者看過 Meltdown 那篇心得的前提來描述 Spectre。

Spectre 的精華在於 CPU 支援 branch prediction 與 out-of-order execution，也就是 CPU 遇到 branch 時會學習怎麼跑，這個資訊提供給 out-of-order execution 就可以大幅提昇執行速度。可以參考以前在「CPU Branch Prediction 的成本...」提到的效率問題。

原理的部份可以看這段程式碼：

這類型程式碼常常出現在現代程式的各種安全檢查上：確認 x 沒問題後再實際將資料拉出來處理。而我們可以透過不斷的丟 x 值進去，讓 CPU 學到以為都是 TRUE，而在 CPU 學壞之後，突然丟進超出範圍的 x，產生 branch misprediction，但卻已經因為 out-of-order execution 而讓 CPU 執行過 y = ... 這段指令，進而導致 cache 的內容改變。

然後其中讓人最驚豔的攻擊，就是論文示範了透過瀏覽器的 JavaScript 就能打的讓人不要不要的...

圖片裡，上面這段是 JavaScript 程式碼，下面則是 Chrome V8 在 JIT 後轉成的 assembly (這是 AT&T style)：

可以從這段程式碼看到，他想要透過這段 JavaScript 取出本來無法存取到的祕密值 index，然後透過 probeTable 得知 cache 的變化。

在這樣的攻擊下，你就可以取得這個 process 裡可以看到的空間，甚至極端的 case 下有可能是 kernel space (配合 Meltdown 的條件)。

不過如果你不能跑 JavaScript 也沒關係，Spectre 的論文裡也提供各種變形方式提供攻擊。像是這樣的程式碼也可以被拿來攻擊：

if (false but mispredicts as true)
    read array1[R1]
read [R2]

其中 R1 是有帶有祕密值的 register，當 array[R1] 有 cache 時，讀 [R2] 就有機會比較快，而沒有 cache 時就會比較慢 (這是因為 memory bus 被佔用的關係)，在這個情境下就能夠產生 timing attack：

Suppose register R1 contains a secret value. If the speculatively executed memory read of array1[R1] is a cache hit, then nothing will go on the memory bus and the read from [R2] will initiate quickly. If the read of array1[R1] is a cache miss, then the second read may take longer, resulting in different timing for the victim thread.

所以相同道理，利用乘法器被佔用的 timing attack 也可以產生攻擊：

if (false but mispredicts as true)
    multiply R1, R2
multiply R3, R4

在論文裡面提到相當多的方法 (甚至連 branch target buffers (BTB) 都可以拿來用)，就麻煩去論文裡看了。現在用 cache 算是很有效的方式，所以攻擊手法主要都是透過 cache 在取得資訊。

Spectre 論文提到的 mitigation (workaround) 是透過 mfence 與 lfence 強制程式碼的順序，但這表示 compiler 要針對所有的 branch 加上這段，對效能影響應該蠻明顯的：

In addition, of the three user-mode serializing instructions listed by Intel, only cpuid can be used in normal code, and it destroys many registers. The mfence and lfence (but not sfence) instructions also appear to work, with the added benefit that they do not destroy register contents. Their behavior with respect to speculative execution is not defined, however, so they may not work in all CPUs or system configurations.

Google 推出的 Retpoline 則是想要避免這個問題。Google 在「Retpoline: a software construct for preventing branch-target-injection」這邊詳細說明了 Retpoline 的原理與方法，採取的方向是控制 speculative execution：

However, we may manipulate its generation to control speculative execution while modifying the visible, on-stack value to direct how the branch is actually retired.

這個方式是抽換掉 jmp 與 call 兩個指令，以 *%r11 為例，他將 jmp *%r11 與 call *%r11 改成 jmp retpoline_r11_trampoline 與 call retpoline_r11_trampoline (這邊的 jmp 指的是所有 jump 系列的指令，像是 jz 之類的)：

retpoline_r11_trampoline:
  call set_up_target;
capture_spec:        
  pause;
  jmp capture_spec;
set_up_target:
  mov %r11, (%rsp); 
  ret;

藉由抽換 %rsp 內容跳回正確位置，然後也利用這樣的程式結構控制 CPU 的 speculative execution。

而在效能損失上，已經有測試報告出來了。其實並沒有像 Google 說的那麼無痛，還是會因為應用差異而有不同等級的效能損失... 可以看到有些應用其實還是很痛：「Benchmarking Linux With The Retpoline Patches For Spectre」。

下半年新出的 CPU 應該會考慮這些問題了吧，不過不知道怎麼提供解法 @_@