インテルの Spectre バリアント 2 (同社のプロセッサ チップのほとんどに影響を及ぼす分岐ターゲット インジェクションの設計上の欠陥) に対する修正は、欠陥を修正するものではありません。
Chipzilla の将来のチップは、機能を無効にしてパフォーマンスの低下を招くことでプロセッサの分岐予測の悪用を防ぐのではなく、少なくともマイクロアーキテクチャの変更が実装されるまでの数年間は、デフォルトで脆弱な状態で出荷されますが、ソフトウェアで設定できる保護フラグが含まれます。
Intelは、Spectreの緩和策に関する技術ノート「投機的実行サイドチャネル緩和策」の中で、そのアプローチを説明しました。IntelはSpectreをバグとして扱うのではなく、Spectre対策を機能として提供しています。
デフォルトで防御を有効にするのではなく、オプトインフラグで欠陥に対処するという決定は、Linuxカーネル管理者のLinus Torvalds氏を激怒させた。
扇動的な暴言で知られるトーバルズだが、期待を裏切らない。日曜日にLinuxカーネルのメーリングリストに投稿されたメッセージで、彼は「現状では、パッチは完全なゴミだ」と書いた。
「これら全ては全くのナンセンスだ。インテルは本当にこんなクソみたいなアーキテクチャを作ろうとしているのだろうか？」と彼は問いかけた。「誰かインテルに話を聞いて、お前らはイカレてるとでも言ったのか？ここにいるインテルのエンジニアの皆さん、頼むからマネージャーに話を聞いてくれ。」
カーネルの最高責任者の発言はこれで終わりではなかった。長年の開発者から、パッチは必要な「厄介なハック」だという指摘に対し、トーバルズ氏は激怒した。
ベテランカーネル開発者 David Woodhouse 氏によって書かれた、パッチに対するより穏やかな反応とコードの説明がここにあります。
トルバルズ氏の怒りは、インテルが将来のプロセッサに Spectre v2 修正プログラムが含まれていることを宣伝すると同時に、IBRS_ALL ビットと呼ばれるフラグを設定することでブート時に修正プログラムを有効にすることを義務付ける計画から生じている。
IBRSは間接分岐制限投機（Indirect Branch Restricted Speculation）の略で、IntelがCPUマイクロコードアップデートとして提供している3つの新しいハードウェアパッチの1つです。このパッチは、Googleが作成した緩和策「retpoline」に加えて提供されます。Intel CPUでSpectreを完全に緩和するには、Chipzillaから入手したこのマイクロコードが必要ですが、後述するように、このマイクロコードは現時点では不安定です。
IBRS は、シングル スレッド間接分岐予測子 (STIBP) および間接分岐予測子バリア (IBPB) とともに、潜在的な攻撃者やマルウェアが分岐予測を悪用して、保護されたカーネル メモリからパスワードやその他の機密情報など、読み取るべきではないメモリを読み取ることを防ぎます。
インテルのチップは分岐予測を用いてプログラムのコードを先読みし、現在の命令の実行を完了しながら将来の処理を行います。CPUがソフトウェアを通して正しいパスを推測した場合、いずれにせよ実行されるはずだったこれらの命令を準備することで時間を節約します。そうでない場合は、投機的に処理した内容を破棄します。
Spectre攻撃は、プロセッサの将来を覗き見できることが危険であることを示しています。Spectre v2攻撃では、CPUの間接分岐予測器を改ざんし、投機的にコードを実行させます。その結果、キャッシュに痕跡が残り、本来コードが覗き見できないカーネルメモリなどの任意のメモリの内容が明らかになります。
マーケティングスピン
ここでの期待は、少なくともトーバルズ氏側では、過去の脆弱性に対処する将来のチップには、カーネルに脆弱性がないことを伝えるフラグまたはバージョン番号が含まれるべきであり、そのため、不要でパフォーマンスを低下させる可能性のある緩和策を適用する必要はない、というものです。言い換えれば、チップはカーネルに対し、ハードウェア設計がSpectre脆弱性を排除するように改訂されており、ソフトウェアによる緩和策や回避策は不要であることを示すべきです。
Intelのアプローチは逆説的で、修正をオプトイン方式としています。プロセッサは、Spectre対策が存在するもののデフォルトでは無効になっていることをカーネルに通知できます。そのため、OS側で有効化する必要があります。おそらく、パフォーマンスの低下があまりにも深刻すぎるためか、Intelが自社のブループリントに致命的なセキュリティ上の欠陥があることを認めたくないためでしょう。
この複雑なアプローチに苛立ちを募らせたトーバルズ氏自身は、インテルの動機は法的責任（20年分の欠陥チップのリコールは莫大な費用がかかる）とベンチマークの不備を回避するためだと示唆した。結局のところ、インテルは既にあらゆるところで訴訟を起こされているのだ。
トルバルズ氏は、既存のハードウェアでIBRSを使用するコストがあまりにも大きいため、誰もハードウェア機能ビットを設定しないだろうと指摘した。「コストが高すぎるので、正気の人間なら誰も使わないだろう」と彼は言った。
速度面でのコストは、使用するハードウェアとワークロードによって異なります。場合によっては無視できるほど小さい場合もありますが、すべてのケースでそうとは限りません。
「Lyftでは、緩和策が展開された際に、AWS C4インスタンス上の特定のシステムコールを多用するワークロードの速度が約20パーセント低下した」とソフトウェアエンジニアのマット・クライン氏は最近の投稿で述べている。
メルトダウン/スペクター第3週: 世界は依然として厄介な事態に陥っている
続きを読む
レジスター紙はインテルに対し、トルバルズ氏の苦情に対処してくれる人がいるかどうか尋ねたが、今のところ返答はない。
インテルは月曜日、関連情報として、Spectre v2攻撃を緩和するためのBroadwellおよびHaswell CPUアップデートに問題があることを明らかにしました。当初のパッチでは影響を受けたマシンがクラッシュする問題が発生していたため、完全なパッチが完成するまで、問題のある部分（Spectre v2の緩和策）を除いたパッチを準備しています。
「OEM、クラウドサービスプロバイダー、システムメーカー、ソフトウェアベンダー、エンドユーザーは、現在の[マイクロコード]バージョンの導入を停止することを推奨します。想定よりも多くの再起動や、その他予期しないシステム動作が発生する可能性があるためです」とインテルは警告し、今月初めに有効だと約束した修正プログラムの展開を事実上凍結した。
業界パートナーの皆様には、アップデートされたソリューションの初期バージョンのテストに注力していただき、リリースを加速させていただくようお願いいたします。リリース時期に関する詳細は、今週中に改めてお知らせする予定です。
HPE は、Lenovo、VMware などに続いて、Intel のファームウェア アップデートをダウンロード ページから削除した最新の企業です。
「更新されたソリューションを最終決定するまでの間、システムの安定性を懸念する人々のために、我々はOEMパートナーと協力して、これらの問題は発生しないが、Variant 2（Spectre）の緩和策を削除した以前のバージョンのマイクロコードを利用するオプションについても取り組んでいる」とIntelは続けた。
システムの安定性を気にしない人にとっては、問題ありません。®
追加更新
この記事が掲載された後、インテルの広報担当者はThe Registerにメールで次のように述べました。「業界パートナーからのフィードバックを真摯に受け止めています。Linus氏をはじめとするLinuxコミュニティと積極的に連携し、解決策の共同開発に取り組んでいます。」
