このMeltdown（Variant3）の仕組み、実は幾つかの前提が整っていないとうまく動かない。1つはCPUパイプラインがスーパースカラー／アウトオブオーダー実行を実装していなければいけないことだ。

　そもそもインオーダーの場合、4行目で保護違反を検知する前に5行目以下の処理が終わる、という事が起き得ない（それが起きたらアウトオブオーダー実行である）し、シングルイシューのパイプラインだと保護違反の検知前に7行目まで実行するのは（処理性能的に）恐らく無理である。

なぜA75は影響を受けて、A72は受けないのか

　ではスーパースカラー／アウトオブオーダー実行が実装されているCPUなら何でもこれが起こり得るのか？　というとそうでもない。

　x86で言えばAMDのZenやSteamroller、K10などのアーキテクチャにこの脆弱性は無いとしているし、ArmでもMeltdownの影響を受けるのはCortex-A75のみで、Cortex-A15／57／72はVariant 3a扱いとされる。

　Variant 3aはArmの説明によれば、7行目にあたる処理を実行できないことを指す。ユーザーモードで動くアプリケーションは、投機実行であってもカーネルページをアクセスしようとするとエラーが出るのでそもそもキャッシュへのロードはできない。であるからして、メモリの内容を傍受するのは不可能である。

　ただしカーネルモードを利用できる一部のシステムレジスターに対してこの操作を行うことは可能なため、その結果としてシステムレジスターの値を間接的に読み出すことは理論上可能だということだ。ちなみにこのVariant 3aの対処については「In general, it is not believed that software mitigations for this issue are necessary.」（一般論として、この問題にソフトウェア的に対処する必要は無いと判断する）とされる。

　そしてCortex-A17／A73の場合は全く問題ない（Variant 3aの問題もない）としており、メモリ／レジスタ共に保護されるということだ。ちなみにAMDについては、同社最高技術責任者（CTO）のMark Papermaster氏に「なぜMeltdownの影響を受けないのか」と直接聞いたものの「細かいことは言えないが、MicroarchitectureがIntelと全く違う」という返事だった。AMD製品は実装がCortex-A17／A73に近いものになっている可能性がある。

　Meltdown対策としてはKPTI（Kernel Page Table Isolation）が有効ということで、現在多くのOSベンダーがこれに基づいたパッチを用意している。本質的な問題は、投機実行のメカニズムにより4行目と7行目でカーネルページへ投機的にアクセスしてしまうことだが、これを助けているのはカーネルページとユーザーページが同じページテーブルを利用していることである。

　なのでそれぞれが別のページテーブルを使うようにすれば、4行目／7行目ともにユーザーモードでカーネルページをアクセスできないので、Meltdownの技法を使ってもデータが読み取れない事になる。

　KPTIには副作用もある。I/Oなどで煩雑にカーネルモード／ユーザーモードの値の受け渡しをする場合、これまでは「共有メモリアドレスにその値を置いて、アドレスを渡すことでデータを送受信する」といった手法を採用していたが、KPTIを利用する際にはカーネル用とユーザー用のメモリアドレスを別個に用意し、この間で相互にデータのコピーを行うという、非常にオーバーヘッドの大きな運用が必要となる。その結果、KPTIによる対策を施した結果、計算中心の処理ではさほど性能は低下しないものの、I/Oプロセッシング系の処理ではそれなりに大きな性能低下が発生することが明らかになっているが、致し方ないところか。