はじめに

2018年、年明け早々に Spectre/Meltdown と呼ばれる CPU の脆弱性が公開されました。

公開当初は影響範囲の大きさと対応の難しさから世界中で大きな話題となりました。弊社でも、主にサービスを支えるインフラが大きな影響を受けるため、劣化する性能や上昇するコストがどのぐらいになるのかを危惧していました。実際には各社・各団体の対応により、当初想定していたほどの影響は受けずにサービスを継続できています。

では、Spectre/Meltdown は完全に収束したのでしょうか？実は攻撃の手法や対象を少し変えた亜種が続々と発見されていて、その中には効果的な対応策が見つかっていないものもあります。

「Spectre/Meltdown は死に絶えていはいなかった」というのがこのエントリの趣旨です。

対策の影響

問題の対応について、影響がごくわずかなものに留まっているものがある一方で、次のように大幅な性能劣化を余儀なくされたり、そもそも対応が難しいケースもあります。

Specter v2 に対する Linux 4.20

Specter v2 は処理効率の改善手法の一つである分岐予測に対して、誤った分岐先メモリアドレスの命令を実行させる問題です。

Linux 4.20 では Specter v2 の緩和策として Single Thread Indirect Branch Predictors（STIBP）を実施予定です。これは Hyper-Threading において論理 CPU 間の分岐予測の制御を防ぐ対応ですが、性能劣化が大きくなってしまい、リーナス・トーバルズ氏はこれをデフォルトで有効にしないように呼びかけています。

TLBleed に対する OpenBSD

TLBleed は論理アドレスと物理アドレスの対応をキャッシュする TLB (Translation Lookaside Buffer) をスレッド間で共有する際に、そのレイテンシ情報からスレッドで実行している情報が取得される問題です。

OpenBSD は TLBleed の対応として、Hyper-threading を無効にする決定を行いました。

Since many modern
machines no longer provide the ability to disable Hyper-threading in
the BIOS setup, provide a way to disable the use of additional
processor threads in our scheduler. And since we suspect there are
serious risks, we disable them by default.
https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html より

Portsmash

比較的最近の11月2日には Portsmash と呼ばれる脆弱性が、OpenSSLで動作するTLSサーバーから秘密鍵を盗み出す PoC と共に公開されました。

ALU などの機能ユニットを共有しているスレッド間で、命令の実行レイテンシ情報から実行中のスレッドの情報を取得できる問題です。

OpenSSL では 1.0.2q で対策されたリリースが行われはいるものの、他のソフトウェアを含めた対策方法としては SMT (Simultaneous Multithreading、Intel での Hyper-Threading) をオフにするしかないようです。

このように、一連の問題についてはまだ収束とは言い難い状況です。

さいごに

Meltdown/Specture のインパクトは非常に大きく、対応に追われた方も多かったと思います。CPU の投機的実行に関する脆弱性は Intel や Microsoft が高額の賞金を設けるなど、現在も研究が行われています。

そのため、2019年以降もしばらくは関連した新たな脆弱性の公表が続くと思います。

また、対策として将来 OS のパッチで根絶できるのか、それとも SMT に匹敵するレベルで最適化処理に全く別のアプローチを行ったアーキテクチャが新たに発明されるのでしょうか？

いずれにせよ、継続的に情報の取得を行い、影響を受ける場合は落ち着いてチームで対応を検討する事を心がけたいと思います。