メルトダウン、スペクターのバグ修正による遅延が現実に ― 対策は？

分析プロセッサ速度をセキュリティより優先することで自ら足を撃ってしまったチップ業界の解決策は、顧客に対しても同じことをすることです。

最近のCPUのほとんどに影響を与えるメルトダウンとスペクターのバグに対処するために導入されているパッチは、本来は取るに足らない些細なものであり、大した影響はないはずだった。ところが、一部の不運な人たちにとっては、まさに錨となるのだ。

Google は、欠陥の発見に協力し、登場し始めたソフトウェア修正は「パフォーマンスへの影響は最小限にとどまる」と主張し、パフォーマンスへの影響は時間とともに減少すると主張した。

インテルは声明の中で、「パフォーマンスへの影響はワークロードに依存しており、平均的なコンピューターユーザーにとっては重大なものではなく、時間の経過とともに軽減されるだろう」と主張している。

プロセッサコンテキストID（PCID）と呼ばれるプロセッサ機能のおかげで、最終的にはそれが実現するかもしれません。しかし、これについては後ほど詳しく説明します。

現時点では、これらのバグへのパッチ適用による速度への影響は深刻であり、注目を集め、苦情も寄せられています。El Regでは、CPUセキュリティバグパッチをできるだけ早く適用することを強くお勧めします。特にクラウドサービスの利用者やIT管理者の方々には、その影響についてご理解いただきたいと考えています。

一般的なデスクトップ ユーザーやゲーマーのほとんどは、長時間の速度低下やパフォーマンスの低下に気付くことはありませんが、バックエンド サーバー上のデータベースなど、IO やシステム コールを集中的に使用するソフトウェアを実行しているユーザーは違いに気付く可能性があります。

Red Hat は、パッチによるパフォーマンスへの影響を 1 ～ 20 パーセントと見積もっています。

エピックゲームズは金曜日、プレイヤーが最近経験したログインと安定性の問題の原因を説明し、「当社のクラウドサービスはすべて、メルトダウンの脆弱性を緩和するために必要なアップデートの影響を受けています」と述べた。

AWSサーバーに依存している同社は、ホストにパッチを適用した後にCPU使用率が急上昇したことを示すグラフのスクリーンショットを公開した。The RegisterはEpic社に調査結果の詳細を求めたが、広報担当者は現時点ではそれ以上の説明はないと述べた。

並列分散ファイルシステムである Lustre のメーリング リストでの議論では、特定の IO 集中型アプリケーションで 10 パーセントから 45 パーセントまでの範囲の速度低下が報告されています。

「zfs+compression+lustre を使用したテストシステムでは、パフォーマンスがひどいことが分かりました」とポツダムのライプニッツ天体物理学研究所のアルマン・カラティアン氏は月曜日のメモに記した。

Redditでは、MoneroコインマイナーがMeltdownパッチ適用後に約45%の速度低下を報告しました。同じスレッドでは、別のマイナーがハッシュレートが10～15%低下したと報告しています。

AWSに依存しているQuoraは土曜日、「インテルのメルトダウンとスペクターの問題に対してAWSが適用したパッチにより、速度低下に直面している」と述べた。

パリを拠点とするブループリント・ストラテジーのデータサイエンティスト、フランシス・ウォリンスキー氏はツイッターで、Windows 7のメルトダウンパッチを適用した後、Pythonの速度が大幅に（約37パーセント）低下したと指摘した。

また、分析会社Branch Metricsのエンジニアリングディレクターのイアン・チャン氏は、Twitterで、Kafkaインスタンスを処理するAWS EC2ハイパーバイザーにメルトダウンパッチを適用した後、CPU使用率が5～20パーセント増加したと説明した。

Amazonの顧客は、The Registerに対し、これまで公に議論されてきたものと同様のCPU使用率の急上昇を示すスクリーンショットを複数提供した。Amazonは週末前に、これらのアップデートによってAWS仮想マシンのパフォーマンスがある程度低下することを認めていたが、「ほとんどの顧客のワークロードに有意なパフォーマンスへの影響はない」としている。

これらの数字は、 The Registerが最初に報じた推定値と一致しており、およそ 5 ～ 30 パーセントのパフォーマンス低下となっていますが、このような結果は非常に変動しやすく、問題の作業負荷や関連するテクノロジーなどの多くの要因に依存するという注意点があります。

El Regの姉妹サイトThe Next Platform は、速度低下により失われるコンピューティング価値の総額は年間 60 億ドルに達すると推定しています。

これらの遅延は主に、Linux 上でカーネル ページ テーブル分離 (KPTI) を通じてカーネルとユーザーの仮想メモリ アドレス空間間の分離を強制する Meltdown パッチの結果です。

Linux以外にも、MicrosoftはWindows Server 2008 R2、2012 R2、2016をはじめとするOSの各種にパッチをリリースしています。AppleもiOSとmacOSのMeltdownとSpectreの脆弱性を軽減しました。

Spectre の緩和策（Google の Retpoline などの対策ツールを使ったソフトウェアの再コンパイルや、プロセッサモデルに応じたマイクロコードの更新など）は、ようやく登場し始めたばかりです。解決には時間がかかる問題に対する部分的な修正に過ぎないと考えられていますが、それでもパフォーマンスにも影響が出ると予想されています（Windows を使用している場合、一部の AMD PC が壊滅的な打撃を受けるだけでなく）。

PCID

これらすべてに明るい面があるとすれば、2010年以降にIntelのx86-64チップに搭載されたPCID機能により、Meltdownのパッチ適用によるパフォーマンスの低下を軽減できることです。（32ビットシステムをお使いの場合は、ご自身で対処する必要があります。）

最新のIntelプロセッサに存在するMeltdownの修正には、ユーザープロセスの仮想メモリ空​​間とカーネルの仮想メモリ領域を完全に分離することが求められます。カーネルを各プロセスの仮想メモリ空​​間の上位にマッピングし、割り込みやシステムコールの処理に必要な場合を除き非表示にするのではなく、独立した仮想アドレス空間とコンテキストに移動します。この修正により、マルウェアがMeltdown CPUバグを悪用してユーザーモードからカーネルメモリを読み取ることを防ぐことができ、カーネルページテーブル分離（KTPI）と呼ばれます。

これらのコンテキスト（ユーザープロセスコンテキストからカーネルコンテキストへ、そして再びユーザープロセスコンテキストへ）の切り替えには、ページテーブルの再読み込みが必要です。ページテーブルは、ユーザープロセスとカーネルを記述する2つのセットから構成されています。これらのテーブルは、プロセスまたはカーネルの仮想メモリを、RAMまたはスワップ領域の物理ブロックにマッピングします。

ユーザープロセスからカーネル、そしてまたプロセスへとコンテキストスイッチを繰り返すことで、時間がかかるだけでなく、キャッシュされた仮想メモリから物理メモリへの変換もすべてフラッシュされ、特にIOやシステムコールを多く伴うワークロードではパフォーマンスの低下を引き起こします。しかし、PCIDを使用すると、選択されたTLBエントリをプロセッサ内に保持できるため、コンテキストスイッチのたびにTLBキャッシュ全体をフラッシュする必要はありません。

PCID は、2017 年 11 月にリリースされた 4.14 カーネルで初めて Linux サポートを導入しましたが、そのため、特に仮想マシンでは、すべての Linux インスタンスで必ずしもデフォルトで利用できるとは限りません。

エンタープライズJava企業Azul SystemsのCTO兼共同創業者であるギル・テネ氏は、日曜日のGoogleグループの投稿で、PCIDはIntelのx86プラットフォームにおけるセキュリティとパフォーマンスの両面で重要になっていると述べた。しかし、同氏は、自身が調査した仮想化Linuxインスタンスの多くではPCIDが存在しないことに気づいた。

Tene氏によると、ほとんどのKVMゲスト（カーネルベースの仮想マシン）にはPCIDが含まれていませんが、VMwareゲストのほとんどには含まれています。また、彼が調べたAWSインスタンスの約半数にもPCIDが含まれていませんでした。

「プロセッサにPCIDは絶対に必要です」とTene氏は書いている。「PCIDがないと、動作が不安定になる可能性があります（Meltdownの修正はデフォルトで無効になっています）。あるいは、動作があまりにも遅くなり、セキュリティ侵害によってこの苦しみから解放されることを望むようになるかもしれません。」

つまり、これらの修正を適用してもパフォーマンスが低下した場合は、カーネル構成を確認し、PCID を有効にしてください（チップセットにハードウェア機能が搭載されている場合）。Windows は、プロセッサによって PCID が提供されている場合は、PCID を使用するはずです。®