本記事は、「MeltdownとSpectre：概要と対処」のフォローアップであり、以下の内容に関する詳細を説明する：Spectre / Meltdownの特徴と潜在的な危険性、クラウド上のVMにクラウドサービスプロバイダがパッチを適用済みであってもなおパッチを当てる必要がある理由、パフォーマンスに悪影響を及ぼす性質と実際のアプリケーションへの影響、脅威モデリングの必要性、アンチウィルスの役割、ハードウェアへの影響、長期的には状況が変わる可能性のあることがら。
SpectreとMeltdownはサイドチャネル攻撃の一例である。Project Zeroのブログ記事では、SpectreとMeltdownの完全かつ複雑な説明がなされている。 Raspberry Piの創始者であるEben Upton氏は、ブログ記事でPiが影響を受けていない理由を簡単に説明している。曰く、「MeltdownとSpectreは、この手の抽象化のコンテキストにおけるセキュリティについて推理し、その結果抽象化と現実の間に軽微な不一致を見つけた場合に、何が起きるかの実例である。」 Graham Sutherland氏は、Twitterスレッドによる解説で核心に踏み込んだ。
副作用をロールバックする際には、2つの重要な除外項目がある。キャッシュと、分岐予測の履歴である。投機的実行はパフォーマンスのための機能であり、キャッシュや分岐履歴バッファ(BHB)の内容はロールバックすると一般にパフォーマンスを低下させるため、これらは通常ロールバックされない。
この事実は、今回の問題に対処する各種のパッチが、なぜパフォーマンスに悪影響を与えてしまうことになるのかも同時に示している。それは、今回のパッチは本質的に、サイドチャネル攻撃が起きそうな場合にはキャッシュと分岐予測履歴を確実にロールバックするようにするものだからだ。技術的な詳細を完全に除いた説明として、Joe Fitz氏は図書館における本に例えた。
Daniel Miesslerは「簡単に説明したMeltdownとSpectreの違い」の中で便利な図を示している。
Spectreの方はパッチの当て方がもっと微妙（more nuanced）だという点からは、ネーミングに対する示唆がある。Meltdownは（パフォーマンスヒットがあるとはいえ）比較的簡単に対処できるが、Spectreの方は（おそらくまだ未発見の問題があり）我々をしばらく悩ませ続けるだろうタイプの問題である。
Google、AWS、Azureはいずれも「弊社のクラウドには（ほぼ）パッチを適用し終えたため、ゲストOSにパッチを適用してください。」と述べた。残念なことに、これらの説明では、ハイパーバイザーとゲストOSの両方にパッチを適用する必要がある理由についての詳しい情報がない。セキュリティ研究者のKatie Moussouris氏は、Robert O'Callahan氏のブログ記事から次の文章を抜粋して強調した。「CPUベンダーとクラウドベンダーは、彼らが導入した軽減策、軽減できていない攻撃、下流となる顧客が問題のどの部分に対して責任を取ることを期待するのか、について正確に伝えることが重要だ。」 AWSの発表で明示的に述べられているのは、「顧客のインスタンスは、他のインスタンスからのこれらの脅威に対して保護されている。」であるが、それが実際に意味しているのは、ある一つのVM内については、アプリケーション間やカーネルに対する攻撃があり得るため、それを防ぐためにVMのOSにパッチを適用する必要があるということだ。これが正しいことはAmazonのRichard Harvey氏によって確認された。
これらの問題に対するパッチを適用すると、アプリケーションがシステムコールを行い、アプリケーションの代わりにOSカーネルに何かをやってもらおうとする時のパフォーマンスに悪影響がある。したがって、ループバックテストは最悪のケースとなる。そのようなテストは、システムコールにすべての時間を費やし、有用な作業には全く時間を費やさないからだ。Intelは、Apple、Microsoft、Amazon、Googleからの声明のまとめを提供したが、それらの声明はおおむねパッチの影響を低く見積もっている。 CloudflareのCTOであるJohn Graham-Cumming氏は「我々は #meltdown と #spectre のためのさまざまなパッチをテストし続けているが、 @cloudflare インフラストラクチャへの影響はごくわずかである。」と述べた。メッセージングライブラリAeronの作者であるMartin Thompson氏は「Windowsでは、Intelのバグパッチを適用するとAeronが驚くほど好成績になる。システムコールのコスト上昇がAeronのバッチ処理を増やし、スループットを向上させているようだ。」と言及したが、後者の状況ではレイテンシに悪影響があった。しかしながら、パフォーマンスへのより深刻な悪影響も報告されている。Syslog_NG伝道者のPeter Czanik氏は、Fedoraのコンパイル時間が4分から21分に上昇したことを確認した（ただし、OpenSUSEではそこまで悪化しなかった）。エンジニアリング部門長であるIan Chan氏は次のように述べた。「当社の本番環境Kaflaブローカーの一部を動かしているAWS EC2 [d2.xlarge] ハイパーバイザーに #Meltdown パッチが（おそらく）適用された。CPU使用率が5〜20％の範囲で相対的に上昇している。グワーッ！」
MicrosoftのJess Frazelle氏は脅威モデルの要点をこう語る。「空が落ちてくると考えるより先に、自分たちの脅威モデルについて考えてみよ。このバグはマシンにアクセスする必要がある。制御されていないコードを実行していないか？それこそがまず心配すべきことである。」ほとんどのサーバーベースのシステムでは、SpectreやMeltdownで攻撃されるには他の手段で既に危険な状態となっている必要がある。また、これらのバグは直接的には特権昇格の手段を提供しない（しかしそのことは、ルートパスワードが読み取られる可能性があるなら些細なことであろう）。エンドユーザーのデバイスは、Webブラウザがかなり普及しているため、危険性がさらに高い。広告などにおけるJavaScriptが危殆化への道となるため、ハイパーバイザーやOSだけでなくブラウザにもパッチが当てられている。
アンチウイルスにもこの問題に関係する部分がある。現時点でMicrosoftは、パッチを適用しても問題ないことを示すレジストリーキーをアンチウイルスベンダーが設定済みであることを確認中である。もしレジストリーキーを設定していないと、アンチウイルスがパッチと衝突するようなメモリアクセスを試み、Windowsをクラッシュさせる可能性がある。いずれは、アンチウイルスと分野的に重複するソフトウェアであるホスト型侵入防止システム（HIPS）が、Spectreを悪用しようとする試みを見つけ出せるようになってくるだろう。
インテルは、CPUマイクロコードの修正を含むOEM向けのファームウェアアップデートをリリースしたが、ソフトウェアパッチが公開されたことから見ると、そのファームウェアアップデート単体では不十分であることが明らかである。 これらの更新プログラムがエンドユーザーにゆきわたるまでには時間がかかるだろう。またマイクロソフトはSurfaceハードウェアに対するアップデートを公開しているため、それが早期の実施例となっている。 AMDの発表では、CPUの脆弱性が軽視されており、パッチによる「無視できるパフォーマンスへの悪影響」が予想されることを示唆している。ARMは、どのアーキテクチャーが影響を受けるかを示す一覧と、その表を広範に補完するホワイトペーパー（PDF）を提供している。ホワイトペーパーでは、問題点と修正方法について、簡潔で徹底した、そしてほぼベンダーに依存しない説明がなされている。興味深いことに、iPhoneとiPadで使用されているARMベースのApple AシリーズCPUもMeltdownの影響を受けているため、投機的実行のアプローチに関してx86から拝借したことが示唆される。ARMは、彼らのコア設計の一部に対して攻撃可能な Meltdownの「変種3a」についても説明しており、攻撃コンセプトを実証するPoCコードが利用可能である。攻撃を緩和するとホワイトペーパーに記載されているCSDBバリア命令は、ARM CPUにすでに存在しており、そのような攻撃の可能性が想定されていたことを示唆しているが、軽減のためのオーバーヘッドは攻撃が実現するまで遅延されていた。
長期的視野に立てば、2つの重要なポイントが浮かび上がってくる。 まずSpectreは、もうしばらく危険性を持つだろう。少なくとも現在のハードウェアが交換されるまでは。つまり組み込みシステムの場合、数十年は危険なままの可能性がある。また、次世代CPUを修正するのでは遅すぎる可能性もある。少なくともリリースサイクルに大幅な遅れがないことが必須だろう。この長い説明が強調しているのは、CPUのリングプロテクションはまったく別の抽象であるということだ。つまり、頑丈な壁で遮られているというより、線が引かれ、笛を持った審判がいるだけのものだ。これらの問題に適切に対処するCPUの世代は、おそらく保護のための頑丈な壁を設計されていなければならないだろう。Joe Fitz氏は次のように述べている。「我々ははじめからやり直さなければならないかもしれない。」