X86プロセッサアセンブルマイクロコードバックドア

私たちはソフトウェアを長い間信用していないため、その監査を実行し、リバースエンジニアリングを実行し、ステップバイステップモードで実行し、サンドボックスで実行します。 ソフトウェアが実行されるプロセッサはどうですか？ -私たちは盲目的に心からこの小さなシリコン片を信頼しています。 ただし、最新のハードウェアにはソフトウェアと同じ問題があります。文書化されていない秘密の機能、バグ、脆弱性、マルウェア、トロイの木馬、ルートキット、バックドアです。

ISA（命令セットアーキテクチャ）x86は、史上最も長く変化し続ける「命令セットアーキテクチャ」の1つです。 1976年に開発された8086設計から、ISAは継続的な変更と更新を受けています。 元の仕様の後方互換性とサポートを維持しながら。 ISAアーキテクチャは40年以上にわたって成長してきましたが、多くの新しいモードと命令セットで成長を続け、それぞれが既にオーバーロードされている以前のデザインに新しいレイヤーを追加しています。 完全な下位互換性のポリシーにより、最新のx86プロセッサには、すでに完全に忘れられている命令とモードが含まれています。 その結果、プロセッサアーキテクチャができました。これは、新しいアンティークテクノロジの複雑な迷路です。 このような非常に複雑な環境-プロセッサのサイバーセキュリティに関する多くの問題を引き起こします。 したがって、x86プロセッサは、重要なサイバーインフラストラクチャの信頼されたルートであると主張することはできません。

プロセッサをまだ信頼していますか？

プログラムとオペレーティングシステムのセキュリティ-それらが展開されているハードウェアのセキュリティに基づいています。 原則として、ソフトウェア開発者は、ソフトウェアが展開されているハードウェアが信頼できず、悪意がある可能性があるという事実を考慮していません。 ハードウェアが誤って（意図的かどうかにかかわらず）動作する場合、ソフトウェアのセキュリティメカニズムはまったく価値がなくなります。 長年にわたり、Intel SGX、AMD Pacificaなどのセキュアプロセッサのさまざまなモデルが提供されてきました。それにもかかわらず、重大な障害（メルトダウンやスペクターなどの最近の障害から）について情報が公開され、文書化されていない「デバッグ」機能が検出されるうらやましい規則性は、プロセッサーに対する私たちの心からの信頼は根拠がないと考えています。

最新のx86プロセッサは、最新のアンティークテクノロジーを非常に扱いにくく複雑に織り交ぜています。 8086には29000のトランジスタ、Pentium 300万、Broadwell 32億、Cannonlakeには100億以上がありました。

トランジスタが非常に多いため、最新のx86プロセッサが文書化されていない命令やハードウェアの脆弱性に悩まされていることは驚くことではありません。 文書化されていないが、ほとんど偶然に発見された命令：ICEBP（0xF1）、LOADALL（0x0F07）、apicall（0x0FFFF0）[1]。保護されたメモリ領域への不正アクセスのためにプロセッサのロックを解除できます。

プロセッサの多数のハードウェア脆弱性（以下の2つの図を参照）については、サイバー攻撃者が特権を昇格できるようにします[3]、暗号化キーを抽出する[4]、新しいアセンブラー命令を作成する[2]、既存のアセンブラー命令の機能を変更する[2] 、アセンブラー命令へのフックのインストール[2]、「ハードウェア加速仮想化」[7]の制御、「原子暗号計算」[7]への介入、最後に「神モード」への移行： 自分自身（あなたも、コンピュータの電源がオフになって、リモートアクセスを受け取ることができます）正当なハードウェアインテルMEバックドアをアイブ。[8] そして、これらすべて-デジタルトレースを残すことなく。

最新のプロセッサはハードウェアよりもソフトウェアです

厳密に言えば、現代のプロセッサは、言葉の意味で「ハードウェア」と呼ぶことさえできません。 最も重要な機能（ISAを含む）は、マイクロコードのフラッシュによって提供されるためです。 当初、マイクロコードは主に、浮動小数点演算、MMXプリミティブ、REPプレフィックス付きのラインハンドラなど、複雑なアセンブラ命令のデコードと実行の制御を担当していました。 ただし、時間が経つにつれて、プロセッサー内部の処理操作のマイクロコードにますます多くの責任が割り当てられます。 たとえば、AVX（Advanced Vector Extensions）やVT-d（ハードウェア仮想化）などのIntelプロセッサの最新の拡張機能は、マイクロコードに実装されています。

さらに、今日では、マイクロコードは、とりわけ、プロセッサの状態の維持、キャッシュの管理、および省電力の管理を担当しています。 エネルギーを節約するために、マイクロコードは電力状態を処理する割り込みメカニズムを実装します。C状態（省エネスリープの程度：アクティブ状態からディープスリープまで）とP状態（電圧と周波数の異なる組み合わせ）。 したがって、たとえば、マイクロコードは、状態C4に入るときと出るときに、L2キャッシュをリセットします。

プロセッサメーカーがマイクロコードを使用する理由

x86プロセッサのメーカーは、マイクロコードを使用して複雑なアセンブリ命令（最大15バイト）を単純なマイクロ命令のチェーンに分解し、ハードウェアアーキテクチャを簡素化し、診断を容易にします。 実際、マイクロコードは、外部（ユーザーに見える）CISCアーキテクチャと内部（ハードウェア）RISCアーキテクチャ間のインタープリターです。

CISCアーキテクチャ（主にISA）でエラーが検出された場合、製造元はマザーボードのBIOS / UEFIまたはオペレーティングシステム（ブートプロセス中）を介してプロセッサにダウンロードできるマイクロコードアップデートを公開します。 マイクロコードに基づいたこのような更新システムのおかげで、プロセッサの製造業者は、機器のエラーを修正しながら、柔軟性とコスト削減を実現しています。 1994年にIntel Pentiumプロセッサをひどくノックダウンしたfdivでのセンセーショナルなミスにより、ハイテクハードウェアエラーがソフトウェアと同様に発生しやすくなることがさらに明白になりました。 この事件により、メーカーはマイクロコードベースのプロセッサのアーキテクチャにさらに関心を寄せています。 そのため、IntelとAMDはマイクロコードテクノロジを使用してプロセッサを構築し始めました。 Intel-1995年にリリースされたPentium Pro（P6）以降。 AMD-1999年にリリースされたK7以降。

すべての秘密が明らかになる

プロセッサメーカーは、マイクロコードのアーキテクチャとマイクロコードの更新メカニズムを厳重に維持しようとしているという事実にもかかわらず、敵は警戒しています。 断片化された情報（主にAMD RISC86 [5]などの特許から）と公式のBIOSアップデートの思慮深い反転（K8 [6]のように）は、徐々にマイクロコードの秘密を明らかにしました（たとえば、下の図を参照AMDプロセッサのマイクロコード更新メカニズム」）。 そして、逆転ツール（ソフトウェアとハ​​ードウェアの両方）の絶え間ない進化[2]、有望なファジング技術[1]、およびMicroparse [9]やSandsifter [10]などのオープンソースツールの出現により、サイバー攻撃者は必要なマイクロコードに関するすべてを学ぶことができますマイクロコードマルウェアを書き込む必要があります。

たとえば、[2]では、「Hello world！」（マイクロコードをトロイの木馬化する最初のステップ）として、プロセッサーがdivコマンドにアクセスした回数を計算する「マイクロフック」（アセンブラー命令をインターセプトするマイクロコードプログラム）が開発されました。 このマイクロフックは、アセンブラー命令divのハンドラーへの注入です。

Ibid [2]は、より高度なマイクロフックを提供します。これは、div ebxのアセンブラー命令に静かに座って存在を示さず、ebx divにアクセスするときに特定の条件が満たされた場合にのみアクティブになります：ebxレジスタには値Bとレジスタが含まれますeaxには値Aが含まれます。アクティブ化されると、このマイクロフックはeipレジスタ（現在の命令ポインター）の値を1つ増やします。 その結果、プログラム（div ebx命令を参照する勇気を持っていた）の実行はオフセットで続行します。divebxに続くコマンドの最初のバイトからではなく、2番目のバイトからです。 eaxおよびebxレジスタで他の値が指定されている場合、ebx divは通常どおり機能します。 これの実用的な価値は何ですか？ たとえば、「重複する命令」[11]を使用した難読化技術を使用する場合、アセンブラ命令の隠されたチェーンを静かにアクティブにします。

これらの2つの例は、正規のアセンブラー命令を使用して任意のトロイの木馬コードを隠す方法を示しています。

同時に、サイバー攻撃者は悪意のあるペイロードをアクティブにすることができます（リモートを含む）。 たとえば、攻撃者が制御するWebページでアクティベーションに必要な条件が満たされた場合。 これは、最新のWebブラウザーに組み込まれたJust-in-Time（JIT）およびAhead-of-Time（AOT）コンパイラーのおかげです。 これらのコンパイラを使用すると、プログラムを高レベルのJavaScriptのみで記述した場合でも（上記の最後のリストを参照）、マシンコードのアセンブラー命令の定義済みストリームを発行できます。