「メルトダウン」エクスプロイトが機能するようにCPUが設計されているのはなぜですか？
私は「メルトダウン」に頭を抱えようとしていますが、最初にそれを理解するために、メモリアクセスを理解しようとしています。
私が理解していることから、CPUは、変換ルックアサイドバッファーで仮想アドレスを検索しようとします。これは、CPUキャッシュ内のデータを示します。そこにあれば、すぐにフェッチします。そうでない場合は、ページテーブルで住所を検索します。
今私の読書から、すべてのプロセスは独自のページテーブルを持っています。ただし、すべてのプロセスには、そのページテーブルにカーネルがマッピングされています。
おそらくページテーブルにもアクセスビットがあります。CPUがユーザーモードのときは、カーネルスペースへの直接の読み取りを許可できません（これは「リング3」と呼ばれていると思います）。
ページテーブルについて私が理解していることから、これらのアクセスビットはアドレスの下位ビットに格納されます。ページエントリは4kであるため、アクセスビットを格納するためのビットがたくさん残っています。
私がエクスプロイトについて読んだことから、問題はデータの取得後にアクセスのチェックが行われることです。これは効率上の理由からです。データをすばやくCPUに取得したいので、永続的な変更を行う前に権限エラーをキャッチできます。しかし、残念ながら、タイミング攻撃を使用して検出可能な間接メモリフェッチを実行することにより、CPUキャッシュに影響を与えています。
このスキームは、ページルックアップは安価であるが、アクセスチェックに費用がかかる場合に意味があります。しかし、私の理解からはそうではないようです。
64ビットマシンでページテーブルを読みましたが、少なくとも3つのレイヤーがあります。つまり、少なくとも3つのメモリルックアップがあります。うまくいけば、これらはキャッシュにありますが、そうでない場合は、ページテーブルを再帰的に検索して自分のページを探します。
この作業をすべて完了し、最終的にページテーブルエントリを見つけたら、ページテーブルから物理アドレスを読み込むときに、アクセスビットも読み込みます。そこでチェックしてみませんか？後で処理するために回路をいじくり回すよりも、既にロードしたアクセスビットをチェックする方がはるかに簡単です。
CPUがどのように動作しているかについて明らかに何かが足りないのですが、何が原因なのかわかりません。何をフェッチするかを決めるために、ページテーブルのルックアップを行う必要があります。問題が発生したら、アクセスビットをチェックするだけではどうですか。
あなたが逃したいくつかのこと：
問題のカーネルメモリはすでにキャッシュにある可能性があり、アクセスビットのフェッチと同じくらい高速にデータをフェッチします。これは、両方のコンテンツアドレス検索です。そうでない場合でも、TLBがあります。完全な3レベルのページテーブルアクセスは、パフォーマンスが目標である場合に最適化するための一般的なケースではありません。
特権レベル自体は、パイプライン内の他のハーフ実行命令によって変更される可能性があります。これらの命令が完全に廃止されるまで、特権レベル自体は単なる推測にすぎません。
＃2がさらに多くの脆弱性の発見につながるのだろうか...
本当の理由は、誰も設計中にセキュリティの問題に気づいていないからです。 CPUを安全に実装できない根本的な理由はありません。あなたの質問は、そのための1つの方法を概説しています。
投機的実行はパフォーマンスを目的としているため、CPUは実際の実行前にできる限り多くの処理を実行しようとしますが、「アーキテクチャの状態」（ソフトウェアが認識できるもの）を変更することはできません。メモリを内部バッファにロードしても状態には影響しないため、好きなときにそれを行うことができます。ただし、アクセス違反が発生すると影響を受けるため、現在のデザインは実際に実行されるまで待機します。 （これは私の側のいくつかの推測です）。
AMDはMeltdownに対して脆弱ではありませんが、それは計画よりも幸運だと思います。メルトダウン紙は、IntelとAMDの両方がアクセス違反の後に投機的ルックアップを実行すると述べています。彼らは、AMDで実用的なエクスプロイトを作成することはできませんでした。
合理的な修正は、投機的ルックアップの前に権限をチェックし、発生した場合は投機的実行を停止することです。実際の実行が追いつくと、割り込みが発生し、サイトへの影響がなくなるのを防ぐことができます。