脆弱性の影響を軽減する軽減策
「MeltdownとSpectreについて知っておくべきこと（前編）」の続きです。
「Meltdown」も「Spectre」も既存ハードウェアの所有者に対しCPUの製造元が直接解決できる問題ではありません。
現場で変更することができないハードウェア設計の問題に起因するものだからです。
全顧客のCPUを交換するわけにもいきませんし、今更修正版Pentium Proを製造するわけにも行かないでしょう。
そこで脆弱性の影響を軽減する軽減策による対応が現実的な対応策になります。
この軽減策は、ソフトウェアのアップデートとCPUのマイクロコードのアップデートの組み合せにより行なわれます。
利用可能な軽減策
軽減策はそれぞれの攻撃ごとに対応しており、異なるパフォーマンスへの影響を与えます。既存の軽減策の要約は、以下のようになります。
| Meltdown | Spectre | |
|---|---|---|
| 軽減策の方針 | ユーザーコンテキストで動作する時は、 カーネルメモリーをアンマップする |
1.投機的実行をより安全に実行するCPUに実装された機能を活用する。 2.安全性が確保されていない状況で投機的実行を行わないようにプログラムを修正する。 |
| 軽減策の形態 | カーネルコードのアップデート | A.カーネルコードのアップデート B.カーネルコードのアップデート C.コンパイラーのアップデート D.アプリケーションコードのアップデート |
| 軽減策で使用する仕組み | KPTI | IBRS IBPB STIBP retpoline |
| 軽減策の適用 | ホスト（ベアメタル）及びゲストのカーネルのアップデート | すべてのホスト及びゲストのカーネルのアップデート。 retpolineによる最適化を活用するためには、すべてのユーザースペースのコードはコンパイルし直さなければならない。 |
| 直接的なパフォーマンスへの影響 | システムコールなどユーザースペースからカーネルスペースのコンテキストスイッチのパフォーマンスが低下する。 例えばディスクからデータを読み込んだりネットワークからデータを読み込むプロセス（ソフトウェア）はすべて影響を受ける。 CPUがPCIDをサポートしているなら、パフォーマンスへの影響を軽減することができる。 |
間接的に分岐を利用しているコードは、パフォーマンスが低下する。 これはインタープリター言語で非常によく使われるパターンである。 現在の軽減策では、すべての分岐予測に対しパフォーマンスへの影響がある。 |
「Spectre」の軽減策のいくつかはまだ十分に成熟しておらず、問題が完全に解決される前に今後さらなる実装やリリースが行われるでしょう。
PCIDについて
「PCID」は2010年以降にリリースされた多くのCPUが持つ機能です。「PCID」は「Linux kernel 4.14」で有効になっていますが、「Ubuntu」では「KPTI」と共にバックポートを行っています。
「PCID」の詳細は、以下を参照してください。
軽減策はどのように展開されるのか？
提供された軽減策の恩恵を受けるには、以下の条件を満たす必要があります。- OS及び影響を受けるアプリケーションは、提供されたパッチが適用されていること
- Spectreに対し完全な保護を実現するには、CPUのマイクロコードかシステムのファームウェアがアップデートされていること
- OSの保護機能が有効になっていること
- 仮想環境では、すべての既知の攻撃から保護するために、ハイパーバイザー及びゲストOSで上記「1.」〜「3.」の内容が実施されていること
Ubuntuでは
「Ubuntu」では、すべての「Ubuntu」ユーザーに無償でセキュリティーアップデートを提供します。提供されるアップデートでは、影響の軽減に必要なすべてのコードと、CPUベンダーからCPUのマイクロコードがリリースされていれば、CPUのマイクロコードのアップデートを自動的にインストールします。
また「Ubuntu」では、デフォルトでは、安定性および安全性が確保された実装によるすべての保護を有効にします。
しかし現在明らかになっているすべての脆弱性に対し、すべての保護が提供されているわけではありません。
また問題は複雑であり、脆弱性に対し有効な保護は、多数のワークロード（一連の処理内容）に大きなパフォーマンスの影響を与えます。
軽減策はどの程度パフォーマンスに影響を与えるのか？
軽減策の導入によるパフォーマンスへの影響は最大の関心事ですが、パフォーマンスへの影響は全体的にワークロードの内容に依存します。「Canonial」による調査では、パフォーマンスが0%〜50%の範囲で低下しました。
テストケース
以下のテストケースで見てみましょう。- 仮想環境では、マイクロコードのアップデートを含む軽減策がハイパーバイザー及びゲストOSで導入されていること。
- パブリッククラウドは軽減策の開発の最先端であり、過去3週間パブリッククラウドの変化を観察した。
以下の結果が見て取れました。
- Spectre対策によるパフォーマンスの低下は、使われているCPUファミリーの種類に依存し、より高度な分岐予測を持つCPUでは、攻撃から保護するのに使用するCPU機能への依存が大きくなる。
- Retpolineはパフォーマンスへの影響を軽減するが、Skylakeプラットフォームでは軽減されない。ただしSkylakeでは、Retpolineがなくてもパフォーマンスへの影響は小さい。
- PCID機能を持ちPCIDが有効になっているCPUでは、Meltdownの軽減策によるパフォーマンスの低下が大幅に軽減される。
デスクトップ環境のユースケース
デスクトップ環境におけるパフォーマンスへの影響を使い方別に分類します。「Ubuntu Desktop」及び「Xubuntu」や「Lubuntu」といったフレーバーが対象です。
また前提として、「Ubuntu」から提供される「Meltdown」と「Spectre」の軽減策の適用、及びすべての保護が有効になっています。
| ユースケース | 顕著なパフォーマンスの低下 | ほとんど影響がない |
|---|---|---|
| 一般的な使い方 | ● | |
| ソフトウェアの開発 | ● |
一般的な使い方とは、メールの読み書きやウェブブラウジング、ドキュメントの作成など、開発以外の使い方です。
多くのデスクトップユーザーは、一般的な使い方になるでしょう。
一方でソフトウェアのビルドやサービスの提供など、ディスクアクセスや全体的に大きく負荷のかかる作業は、ソフトウェアの開発に分類されます。
サーバー環境のユースケース
サーバー環境におけるパフォーマンスへの影響を使い方別に分類します。「Ubuntu Server」やサーバー目的の利用がこちらに該当します。
こちらも前提として、「Ubuntu」から提供される「Meltdown」と「Spectre」の軽減策の適用、及びすべての保護が有効になっています。
| ユースケース | 深刻なパフォーマンスの低下 | 顕著なパフォーマンスの低下 | ほとんど影響がない |
|---|---|---|---|
| ビルドやテスト | ● | ||
| ロードバランサーやウェブキャッシュ | ● | ||
| VFNアプリケーション（EPC/IMS） - DPDKなし | ● | ||
| ストレージ分析ツール（AV/duなど） | ● | ||
| HTTPアプリケーションサーバー | ● | ||
| ビッグデータ（Hadoop/Spark） | ● | ||
| SQL/NoSQLデータベース | ● | ||
| インメモリーデータベース | ● | ||
| VFNアプリケーション（EPC/IMS） - DPDKあり | ● | ||
| カーネル内で行うルーティング及びファイアーウォール | ● |
「du」に関しては、「Spectre」の軽減策を導入した環境において、何度も繰り返し実行した結果、50%のパフォーマンスの低下が計測されています。
HTTPアプリケーションサーバーやロードバランサーは、ユーザースペースでの実装を前提としています。
実際に計測して見ることが大切
特に多くのユーザーにサービスを提供するような使い方では、実際にパフォーマンスを測定し、要件を満たしているかどうか確認することが大切です。上記でパフォーマンスへの影響が小さいと紹介されていても、それが実際にサービスを提供する側の要件を満たすかどうかは別の話です。
上記の表はあくまで影響を一般化した時の影響の度合いですので、ユースケースの組み合わせやワークロードの内容により、パフォーマンスへの影響が変わってきます。
軽減策の制御
導入された軽減策は、デフォルトでは有効になりますが、個別の軽減策に対し有効/無効を切り替えることが可能です。詳細は、以下を参照してください。
利用可能なパフォーマンスの計測データ
「Canonical」はパブリッククラウド及びプライベートクラウド、そしてアプリケーションの横断的なパフォーマンス計測データを作成中です。「Canonical」は2018年2月12日までに公開された軽減策を適用し、内部の計測に基づく評価の作成を目的としています。
現在の一例として、Skylakeのビルドファームに「Meltdown」と「Spectre」の軽減策及びプレリリース版のIntelマイクロコードのアップデートを適用した環境で、以下の現象が確認できています。
- カーネルのビルド時間が50%増加した。軽減策の適用前では平均3.5時間だったが、軽減策適用後は平均5時間かかかるようになった。
- 全体的なパッケージのビルド時間が、30%増加した。
アプリケーションパフォーマンス
以下のページにて、アプリケーションパフォーマンスのまとめが紹介されています。このページに記載されているデータは、信頼性の高いサードパーティーが公開したパフォーマンスデータに基づいています。
