クラウドの仮想サーバーに“CPU脆弱性対策の影響”が出ている
サーバーに脆弱性が見つかったならばOSパッチやCPUマイクロコードを更新して対策するのが普通だ。と、思っていたけれど、通常の仮想サーバーの性能を 100% とした場合、対策後の仮想サーバー性能が 60% 程度までダウンしているなら話は別だ。100% の性能を発揮させるにはどうすべきか記述する。
※ セキュリティに関するお話なので、ここまで書いておいて、最後は自己責任となります事、ご配慮ください。
調査対象
CPU脆弱性対策の影響を受けているクラウドの仮想サーバーを確認すべく、**AWS、Azure、GCP、IBM Cloud (SoftLayer)**について、それぞれの仮想サーバーのベンチマークを実施。クラウドベンダーの名前は伏せている。仮想サーバー（＝ゲストVM）での話だが、Meltdownは全てのクラウドベンダーで対策済みだったが、Spectreは対策していないベンダーもあった（物理クラウド基盤は対応されていると思われる[確認できず]）。
結果、遅くなっていた
本来あるべき仮想サーバーの性能に対して、2018年1月以降に新たにデプロイ(払い出)した仮想サーバーの性能をUnixBenchスコアで計測した。
1vCPU の場合、約56.3%の性能（つまり43% 性能ダウン）
2vCPUの場合、59.8%の性能ダウン（本来の1vCPUより性能低いって最悪）
4vCPUの場合、35.5%の性能ダウン（最新の4vCPUは、従来の2vCPUと同等）
どうするべきか
- 第三者に投機的実行時のメモリを読み取られる可能性が現時点では限りなく低い事、自分の仮想サーバーで扱うデータの秘密性が低いなら、CPU脆弱性の対策はやらない判断をする、のもアリ。
- Intelは再起動問題があるので、アップデートすることを控えるよう呼びかけている
- CPU脆弱性の内容について、他の方々が説明してくれているので割愛する。
- RedhatのWebサイトでは、CPU脆弱性対策を無効にする方法をわざわざ説明している。
- MicrosoftのWebサイトでも無効にする方法を説明している。
対策を無効化して、本来の性能を取り戻す
CPU脆弱性対策を無効にして、仮想サーバー本来の性能を 100% 発揮する設定手順の確認と、その結果を計測する。
予備知識
CPU脆弱性対策は３つある。
CVE-2017-5753 (#1/Spectre) は、無効にできません。
CVE-2017-5715 (#2/Spectre) に、CPUマイクロコードと連携する (1)ibrs と (2)ibpb の２つのパラメータがある。
CVE-2017-5754 (#3/Meltdown) は、OSカーネルパッチで修正される (3)pti のパラメータがある。
検証結果サマリー
パラメーターに'0'をセットするとその対策を無効にすることができる。３つとも無効にした状態の性能を100%として比較する。仮想サーバー払出し直後は 44%（つまり３つとも有効の時は遅いのです）（３台の平均が 65% だったので、この検証用サーバーは極端に遅い）
| 設定 | 1vCPU | 2vCPU | 2vCPU性能差 |
|---|---|---|---|
| 3つとも有効 | 401.5 | 730.0 | 44% |
| (2)ibpbだけ無効 | 400.6 | 729.1 | 44% |
| (3)ptiだけ無効 | 431.9 | 789.2 | 47% |
| (1)ibrsだけ無効 | 827.7 | 1418.4 | 85% |
| (1)ibrsと(2)ibpbの2つを無効 | 835.4 | 1414.6 | 85% |
| 3つとも無効 | 1065.5 | 1667.3 | 100% |
結論
つまり、Meltdown対策をしても性能影響は小さい(+3%)。Spectreは、ibpbだけ無効にしても変化なし、ibrsを無効にするだけで+41% 向上した。ibrsとibpbをセットで無効化してもあまり変化なかった。
検証準備
仮想サーバーを払い出した直後のUnixBenchスコアを計測する（つまり対策が有効な状態）。2 vCPUでの期待値を 1588 とした場合、実測スコア 951.5 は、40% の性能ダウン。
検証１
CPU脆弱性対策の [pti] だけを無効化して、UnixBenchスコアを計測する。9% だけ改善した。
# echo 0 > /sys/kernel/debug/x86/pti_enabled
# echo 1 > /sys/kernel/debug/x86/ibpb_enabled
# echo 1 > /sys/kernel/debug/x86/ibrs_enabled
検証２
CPU脆弱性対策の [ibpb] だけを無効化して、UnixBenchスコアを計測する。ほぼ変化なし。
# echo 1 > /sys/kernel/debug/x86/pti_enabled
# echo 0 > /sys/kernel/debug/x86/ibpb_enabled
# echo 1 > /sys/kernel/debug/x86/ibrs_enabled
検証３
CPU脆弱性対策の [ibrs] だけを無効化して、UnixBenchスコアを計測する。90% 改善した。
# echo 1 > /sys/kernel/debug/x86/pti_enabled
# echo 1 > /sys/kernel/debug/x86/ibpb_enabled
# echo 0 > /sys/kernel/debug/x86/ibrs_enabled
検証４
CPU脆弱性対策の [ibrs] と [ibpb] の２つを無効化して、UnixBenchスコアを計測する。98% 改善した。
# echo 1 > /sys/kernel/debug/x86/pti_enabled
# echo 0 > /sys/kernel/debug/x86/ibpb_enabled
# echo 0 > /sys/kernel/debug/x86/ibrs_enabled
検証５
CPU脆弱性対策の３つ全てを無効化して、UnixBenchスコアを計測する。104% 改善した（2倍のスコアが出た）。
# echo 0 > /sys/kernel/debug/x86/pti_enabled
# echo 0 > /sys/kernel/debug/x86/ibpb_enabled
# echo 0 > /sys/kernel/debug/x86/ibrs_enabled
検証６
検証１～５の手順は一時的な無効化作業であり、仮想サーバーを再起動すると再び対策が有効になってしまう。仮想サーバーを再起動しても対策を無効にするには、カーネルのコマンドラインでパラメータを無効にする設定をする。
▼ viで、/etc/default/grub に noibrs noibpb nopti を追加。その結果↓
# cat /etc/default/grub
GRUB_CMDLINE_LINUX="vconsole.keymap=us crashkernel=auto vconsole.font=latarcyrheb-sun16 noibrs noibpb nopti"
▼ 設定ファイルを出力する
# sudo grub2-mkconfig -o /boot/grub2/grub.cfg
▼ ファイルに記載されていることを確認する。
# cat /boot/grub2/grub.cfg | grep nopti
▼ 再起動する
# sudo reboot
▼ 反映されていることを確認する（0ならオッケー）。
# cat /sys/kernel/debug/x86/ibpb_enabled
0
UnixBench 項目別スコア
CPU脆弱性対策は、下図左の２つ（整数プログラミング、浮動小数点演算）以外で影響を受ける様子。
脆弱性対策されているか診断するスクリプト
次のスクリプトを実行すると、実行した仮想サーバーの[Spectre]と[Meltdown]の対策がされているか、３つの脆弱性について[STATUS:]の部分で「脆弱性あり・脆弱性なし」で教えてくれる（なお、クラウド基盤側の物理サーバーは、クラウドベンダーが対応したとアナウンスしている）。
# wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
# chmod +x spectre-meltdown-checker.sh
# sudo sh ./spectre-meltdown-checker.sh
まとめ
改めて「自己判断で実施を検討してください」。
・（遅くなっている）CPU脆弱性の対策をしている結果、仮想サーバーの性能が40%程度ダウンしている。
・（本当に必要な対策なのか）CPU脆弱性リスクを理解し、仮想サーバーで扱うデータの秘密性を考慮する。
・（対策を保留にできる）CPU脆弱性対策を無効化することで、本来の仮想サーバーの性能を最大限に取り戻せることが分かった。
・（今後）Intelが恒久対策を公開すると性能問題の状況が変わると思います。というかみんな期待していると思います。お願いだからデータセンターレベルでの全面計画保守するのだけは避けてほしい。
以上