VMMを用いたタイミングベースサイドチャネル攻撃に対する緩和策
- 5. Spectre, Meltdown
● 細かい違いはあるが本質的には同じ
○ 高速化のために暗黙的に行われる動作の副作用をキャッシュから読み取る
● Meltdownの例
○ CPUには高速化のために先読みしてコードを実行する機能がある
○ 投機的実行がされる時はメモリのアクセスに対する保護が働かない
○ 先読みした結果が頻繁に当たるとキャッシュされる
○ 意図的にキャッシュを学習させて、ヒットしたか否かで別の範囲にある値をリーク
■ キャッシュヒットの発生は時間を計測することで検知可能
- 7. 提案手法
● サイドチャネル攻撃に必要な情報を欠落させる
○ タイミングベースのサイドチャネル攻撃には高精度な時間計測が必要
○ タイマーの精度が十分に低い場合、攻撃は失敗する
● タイムスタンプカウンタとして使われる命令にノイズを載せる
○ RDTSC
○ RDTSCP
○ cf. BitVisor Summit 7 筑波大学 大山恵弘 "BitVisorによるOSの見かけ上10倍速実行"
■ https://www.bitvisor.org/summit7/slides/bitvisor-summit-7-4-oyama.pdf
● 適当な乱数を発生させ、戻り値に加算
● BitVisorで実装
○ OSに手を加えること無くベアメタル環境で適用可能
- 8. 補足
● LinuxはRDTSCが信用できるかを監視する
● 不安定になるとHPETに切り替える
○ tsc=reliable をカーネルパラメータに追加すると常に RDTSCを使う
[ 80.981566] clocksource: timekeeping watchdog on CPU4: Marking
clocksource 'tsc' as unstable because the skew is too large:
[ 80.981569] clocksource: 'hpet' wd_now: 711dec8a
wd_last: 6b7744b2 mask: ffffffff
[ 80.981570] clocksource: 'tsc' cs_now:
37fffa04eb cs_last: 34f815eaa0 mask: ffffffffffffffff
[ 80.981573] tsc: Marking TSC unstable due to clocksource watchdog
[ 80.981625] TSC found unstable after boot, most likely due to broken
BIOS. Use 'tsc=unstable'.
[ 80.981626] sched_clock: Marking unstable (80611443013,
376117789)<-(81685895057, -704289633)
[ 80.987560] clocksource: Switched to clocksource hpet
- 11. 考察
● そもそも攻撃自体が安定しない
○ 通常状態では80~90%程度
○ 少ないノイズだとむしろ成功率が上がっている?
○ PCの状態 (画面OFFなど) の影響も考慮する必要がある
● 5000 (±2500) でほぼ失敗する
○ 体感では動作そのものに影響は生じていない
○ LinuxのTSC検知機能にも引っかからない
○ 汎用的なmitigationとしては成功している