Linuxの最高責任者であるリーナス・トーバルズ氏は、最新のプロセッサのデータ漏洩脆弱性であるスペクターバリアント2に対する、これまで導入されていた防御を制限するカーネルパッチへの支持を表明した。
具体的には、提案されたパッチは、特定のSpectre V2防御メカニズムを自動的に有効化するのではなく、デフォルトで無効化します。この変更が提案されている理由は、ハイパースレッディングを使用するIntel CPUでこのセキュリティ防御を有効にすると、コードの実行速度が最大50%低下するからです。
ご存知ない方のために説明すると、ハイパースレッディングとは、Chipzillaによる同時マルチスレッディング（SMT）の実装です。これは、個々のCPUコアを2つのハードウェアスレッドに分割する技術です。そのため、各コアはほぼ2つのソフトウェアを同時に実行できます。つまり、例えば12コアのプロセッサは24のハードウェアスレッドを持つため、オペレーティングシステムとソフトウェアからは実質的に24コアのチップとして認識されます。
SMTは、アプリケーションによってメリットとデメリットがあり、その効果はアプリケーションによって異なり、その目的や方法によって異なります。あるハードウェアスレッドで実行されるコードが、共有CPUコア内の同じスレッドで実行される別のアプリケーションをスヌーピングする可能性があることは、以前から知られており、対策も講じられてきました。しかし、Spectreファミリーの脆弱性によって、このセキュリティ上の悩みの種であるパンドラの箱が再び開かれました。SMTと一部のSpectreカーネル緩和策がうまく連携せず、パフォーマンスの低下につながるからです。
STIBP THBIS 非セプンセ
今回のSpectre V2の具体的な緩和策は、Linux 4.20に追加され、Linux 4.19.2にバックポートされました。STIBP（Single Thread Indirect Branch Predictors）と呼ばれるこの緩和策は、コンピュータ上のマルウェアがプロセッサの分岐予測エンジンを悪用し、本来アクセスすべきではないメモリからパスワード、暗号鍵、その他の機密情報を盗み出すことを防ぎます。
防御機構はパフォーマンスを著しく低下させることが判明したため、Torvalds 氏は、すべてのケースでデフォルトで有効にすべきではないと考えています。
「一部の負荷でパフォーマンスが50%も低下した場合、人々はそれが本当に価値があったのか自問自答し始める必要がある」と、トーバルズ氏は日曜日にLinuxカーネルのメーリングリストに宛てたメッセージで述べた。「どうやらSMTを完全に無効にした方がよさそうだ。セキュリティ意識の高い人々は、とにかくそうしているのだ。」
SUSE Labs のコア カーネル チームのディレクターである Jiri Kosina 氏は、実際の Spectre Variant 2 攻撃では、あるブラウザー タブの JavaScript が別のタブのプライベート データを狙う可能性があると示唆しましたが、Torvalds 氏は懐疑的な見解を示し、それは Meltdown の脆弱性よりもはるかに理論的なものだと主張しました。
ブラウザには、Spectreを悪用して情報を盗むタブに対する独自の防御機能が組み込まれており、現在までに、MeltdownやSpectreのプロセッサ脆弱性を悪用するマルウェアやスパイウェアが実際に存在するという報告はありません。使用するアプリケーションの種類や実行環境によっては、Spectreのセキュリティ防御によるパフォーマンスの低下が、ハッキングされるリスクを上回る可能性があります。
「普通の人間ユーザーに対する、実際に現実的な攻撃を見たことがありますか？」とトーバルズ氏は言った。「カーネルが実際に気にすべきことは何ですか？JavaScriptの問題はブラウザが修正するものであり、カーネルが『これですべての動作が最大50%遅くなるはずです』と指示するものではありません。」
「一体何が起こっているんだ？」リーナス・トーバルズ、インテルがスペクター修正をセキュリティ機能だと偽っていることに激怒
続きを読む
STIBPの影響を深刻に捉えている人は必ずしも多くありません。Intelのオープンソース技術センターのエンジニア、ティム・チェン氏によると、SpecInt Rate 2006テストスイートを用いてSTIBPをperlbenchで実行すると、スループットが21%低下するそうです。ただし、実際の速度低下の指標はワークロードとハードウェアによって大きく異なります。
Torvalds 氏は、STIBP を有効にするパッチを元に戻す必要性を感じていませんが、STIBP は「人々に伝えられていたよりも明らかにずっと高価だった」ため、デフォルトの動作ですべてのケースにおいて無条件に有効にするべきではないという点では他の人たちと同意見です。
そのため、現在開発中のパッチでは、管理者が必要に応じてSTIBPを有効化できるようになりますが、IntelのL1 Terminal Fault（L1TF）脆弱性の緩和策と同様に、デフォルトで有効化されるわけではありません。LinuxのリーダーであるTorvalds氏のやり方を研究する人なら、1月に（癇癪を起こす前の）IntelのSpectreおよびMeltdownに対する初期のパッチの品質に激怒していたことを覚えているかもしれません。
要約すると、 STIBP のオプションは次のとおりです。
- セキュリティ上の理由から STIBP を有効にし、ハイパースレッディングを有効にします。これにより、ワークロードにメリットがもたらされ、ソフトウェアの速度低下による影響を回避できます。
- セキュリティ上の理由から STIBP を有効にし、ワークロードにメリットがないため、または他の HT 関連の脆弱性を軽減したいため、ハイパースレッディングを無効にします。
- セキュリティ リスクを心配していない場合は STIBP を無効にし、ワークロードにメリットがあるためハイパースレッディングを有効にします。
- セキュリティ リスクを心配していない場合は STIBP を無効にし、アプリケーションがハイパースレッディングの恩恵を受けていない、または他の HT 関連の脆弱性を軽減したい場合にはハイパースレッディングを無効にします。
Intel フェローであり Linux カーネル開発者でもある Arjan van de Ven 氏は、STIBP をデフォルトで有効にすることに反対する意見に加わりました。
「AMDはドキュメントの中で、デフォルトでこれを推奨しないことを公式に推奨しています。Intelの立場も同じく、これはデフォルトでオンにすべきではありません」と彼は述べた。「…これらのツールをより慎重に使用するのは問題ありません。例えば、パラノイア的なタスクでオンにする必要がある場合や、ハードコアなセキュリティ移行を行っていることが分かっている場合などです。しかし、常にオンにするのはどうでしょうか？ うわぁ。」®
PS: OpenBSD では、セキュリティ上の理由から Intel Hyper-Threading を無効にすることを推奨しています。
